-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ResolvePackageFileConflicts Prohibits using DbgShim from NuGet package #90187
Comments
@tommcdon do you happen to know who owns dbgshim on the runtime side and might have guidance on the best way to reverence it separately from the shared framework? |
@marcpopMSFT Dbgshim was removed from the 7.0 runtime and now lives in dotnet/diagnostics, shipping as an out-of-band nuget package. Given that it no longer ships with the runtime, it feels like we should remove it from |
@mikem8361 @hoyosjs any thoughts on this and recommendations for the customer? |
@jkoritzinsky to me it makes sense to remove from the platform manifest. Is there anything that breaks other than rollforward (from one that has dbgshim to one that doesn't will break)? Since all supported runtimes don't have it only .NET 5 and bellow will break when running on a 6.0+ runtime, but that's an OK tradeoff. |
The main use case for the PlatformManifest is to ensure that in-box assets take precedence over packaged assets even if renamed. In this case, we've moved an in-box asset to out-of-box, so removing it from the manifest makes sense. This shouldn't break downlevel apps as the in-box asset will always be preferred for platforms like .NET 5. |
Per comments above, moving to runtime repo. |
Tagging subscribers to this area: @tommcdon Issue DetailsWhen developing a .NET debugger capable of targeting .NET Core applications, a library called Microsoft has shipped a NuGet package for If you attempt to reference this NuGet package however, neither After doing some debugging, I have identified that the reason The sequence of events that lead up to the conflict being detected are as follows:
If DbgShim is removed from In dotnet/sdk#2221 an issue similar to this is described, and there is a workaround in the code to deal with this, however it seems this workaround is predicated on having a "reference" of some kind to the conflicting assembly, which isn't the case when we've got a native, unreferenced library. As a creative workaround, I attempted to add a target to "enhance" the list of package overrides with the goal of telling the conflict resolver to use my package as per this line <Target Name="Hack" BeforeTargets="_HandlePackageFileConflicts">
<ItemGroup>
<PackageConflictOverrides Include="Microsoft.Diagnostics.DbgShim.win-x64">
<!-- Use an arbitrarily high number so we always win -->
<OverriddenPackages>
Microsoft.NETCore.App.Ref|99.0
</OverriddenPackages>
</PackageConflictOverrides>
</ItemGroup>
</Target> Unfortunately, I found this does not work because the platform I'm not sure whether I would recommend having
|
When developing a .NET debugger capable of targeting .NET Core applications, a library called
dbgshim
is used to bootstrap the entire process. Whiledbgshim
is included with the .NET Runtime, it is generally recommended to shipdbgshim
with your application so that your debugger doesn't have to worry about locatingdbgshim
on the target system; simply load yourdbgshim
into your debugger, point it at a given process and ask "does this process host a CLR we can attach to?"Microsoft has shipped a NuGet package for
dbgshim
that includes sub-packages with nativedbgshim
implementations for all of the various operating systems/architectures it supports.If you attempt to reference this NuGet package however, neither
dbgshim
nor theruntimes
directory inside the sub-packages are copied to your output folder, regardless of whether you are doingdotnet build
ordotnet pack
. For the purposes of developing an application, I expect these files should be copied to the output directory upon doingdotnet build
(so that you can find and load them in your application)After doing some debugging, I have identified that the reason
dbgshim
does not get copied to the output directory is that the version ofdbgshim
in the package is considered to conflict with the version ofdbgshim
included in the runtime, and thus the runtime always wins.The sequence of events that lead up to the conflict being detected are as follows:
The ResolvePackageFileConflicts task is run
PlatformManifestReader reads a
PlatformManifest.txt
file for the current runtimeAs
dbgshim
is listed in this file, a conflict item is added for itConflictResolver tries to resolve the platform dbgshim against the NuGet package dbgshim
PackageOverrideResolver is called upon to see if there are potentially any overrides that could be taken advantage of
As there are no overrides, the platform dbgshim wins by virtue of having a higher file version and you get the following error in the MSBuild log
If DbgShim is removed from
PlatformManifest.txt
,dbgshim
and/or theruntimes
folder is copied to the output directory upon building, as expectedIn dotnet/sdk#2221 an issue similar to this is described, and there is a workaround in the code to deal with this, however it seems this workaround is predicated on having a "reference" of some kind to the conflicting assembly, which isn't the case when we've got a native, unreferenced library.
As a creative workaround, I attempted to add a target to "enhance" the list of package overrides with the goal of telling the conflict resolver to use my package as per this line
Unfortunately, I found this does not work because the platform
dbgshim
has anull
PackageVersion
, hence the check in thisif
statement failsI'm not sure whether I would recommend having
dbgshim
simply be omitted fromPlatformManifest.txt
, as this file may be used for other purposes as well. Arguably,dbgshim
is kind of a special case, so potentially there could just be special rules for how to handle conflicts againstdbgshim.dll
,libdbgshim.so
andlibdbgshim.dylib
The text was updated successfully, but these errors were encountered: