-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
P2Ps should be allowed when ReferenceOutputAssembly=false even given TFM incompatibilities #939
Comments
Workaround: Try also adding SkipGetTargetFrameworkProperties=true metadata to the reference. |
Thanks @nguerrera. But that doesn't work either. That causes a referencing project A to build the referenced project B per A's TargetFramework value instead of B's TargetFramework. |
Ah, I believe this would only happen if A is multi targeted. Is it? Try adding UndefineProperties="TargetFramework" metadata as well. |
Yes, Should we leave the issue active for making this scenario simpler, and/or work the way it used to? |
Yes, this should work without the extra metadata. |
- add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks because dotnet/sdk#939 workarounds fail in this scenario Improve project-to-project reference handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Add `api-check --compact-output` option - use this option in the task - separately, catch and log `FileNotFoundException` - output types and stack traces of caught `Exception`s nits: - update solution to use current project type GUID - apply VS suggestions e.g. `out var` - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates
- aspnet/KoreBuild#143 Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks; dotnet/sdk#939 workarounds fail in this scenario Fall back to `RuntimeTargets` when `RuntimeAssemblies` yields no assemblies Improve project-to-project reference and native assembly handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - catch and ignore `BadImageFormatException` in `AssemblyLoadContext.GetAssemblyName()` - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Change ApiCheck.exe's options and output - add `api-check --compact-output` option - generally make tool's output more useful to the task - catch and log `FileNotFoundException`; output types and stack traces of caught `Exception`s - remove `--framework` option; unused in .NET Framework already - change ApiCheck.exe option from `--ApiListing` to `--api-listing` for consistency w/ other options nits: - remove `PackageGraph.RuntimeIsCompatible()` `candidateRuntime` parameter - not needed and confusingly-named; passed value included in `compatibleRuntimes` - update solution to use current project type GUID - ignore global.json and launchSettings.json - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj - make a couple of constructors `private`; used only in `public static` methods - ignore case a bit more notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates
- aspnet/KoreBuild#143 Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks; dotnet/sdk#939 workarounds fail in this scenario Fall back to `RuntimeTargets` when `RuntimeAssemblies` yields no assemblies Improve project-to-project reference and native assembly handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - catch and ignore `BadImageFormatException` in `AssemblyLoadContext.GetAssemblyName()` - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Change ApiCheck.exe's options and output - add `api-check --compact-output` option - generally make tool's output more useful to the task - catch and log `FileNotFoundException`; output types and stack traces of caught `Exception`s - remove `--framework` option; unused in .NET Framework already - change ApiCheck.exe option from `--ApiListing` to `--api-listing` for consistency w/ other options nits: - remove `PackageGraph.RuntimeIsCompatible()` `candidateRuntime` parameter - not needed and confusingly-named; passed value included in `compatibleRuntimes` - update solution to use current project type GUID - ignore global.json and launchSettings.json - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj - make a couple of constructors `private`; used only in `public static` methods - ignore case a bit more notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates
- aspnet/KoreBuild#143 Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks; dotnet/sdk#939 workarounds fail in this scenario Fall back to `RuntimeTargets` when `RuntimeAssemblies` yields no assemblies Improve project-to-project reference and native assembly handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - catch and ignore `BadImageFormatException` in `AssemblyLoadContext.GetAssemblyName()` - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Change ApiCheck.exe's options and output - add `api-check --compact-output` option - generally make tool's output more useful to the task - catch and log `FileNotFoundException`; output types and stack traces of caught `Exception`s - remove `--framework` option; unused in .NET Framework already - change ApiCheck.exe option from `--ApiListing` to `--api-listing` for consistency w/ other options nits: - remove `PackageGraph.RuntimeIsCompatible()` `candidateRuntime` parameter - not needed and confusingly-named; passed value included in `compatibleRuntimes` - update solution to use current project type GUID - ignore global.json and launchSettings.json - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj - make a couple of constructors `private`; used only in `public static` methods - ignore case a bit more notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates
- aspnet/KoreBuild#143 Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks; dotnet/sdk#939 workarounds fail in this scenario - bump ApiCheck package version Improve project-to-project reference and native assembly handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - catch and ignore `BadImageFormatException` in `AssemblyLoadContext.GetAssemblyName()` - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Fall back to `RuntimeTargets` when `RuntimeAssemblies` yields no assemblies Change ApiCheck.exe's options and output - add `api-check --compact-output` option - generally make tool's output more useful to the task - catch and log `FileNotFoundException`; output types and stack traces of caught `Exception`s - change ApiCheck.exe option from `--ApiListing` to `--api-listing` for consistency w/ other options Use Microsoft.Extensions.CommandLineUtils.Sources package - VersionTool project cannot do this because it has `public` properties of these `internal` types Update appveyor.yml now that VS 2017 RC image is no more nits: - remove `PackageGraph.RuntimeIsCompatible()` `candidateRuntime` parameter - not needed and confusingly-named; passed value included in `compatibleRuntimes` - update solution to use current project type GUID - ignore global.json and launchSettings.json - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj - make a couple of constructors `private`; used only in `public static` methods - ignore case a bit more - remove duplicate `<PropertyGroup>` from `NugetReferenceResolver` project - get this repo building on Linux - don't need API checks in this repo - centralize a few more properties in dependencies.props notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates
This is badly broken. The workaround causes nuget restore to fail in VS (command line is fine) and also is related to a build failure that only occurs on some non-Windows machines including Travis CI Ubuntu. I tried replacing this with a "project dependency" encoded in the solution file, and that fixed most of the symptoms, until I tried This inability to influence build ordering is really causing some pain here. Please fix soon! |
Has anyone found a workaround that is close to successful? For a minimal netstandard1.X project reference to a netcoreapp1.X project:
Interestingly enough when I restore and build from MSBuild directly the |
No. I finally gave up and checked the binary into git so I didn't need a project reference. I tried for days but never found a way that got dotnet build, msbuild, and VS to all work correctly at once. 😦 |
This can be worked around by adding an outside-the-norm order dependency in MSBuild, by way of a custom call to the <Target Name="WorkaroundSdk939" BeforeTargets="ResolveProjectReferences">
<MSBuild Project="..\..\the\other.csproj" />
</Target> Note that depending on your specific needs, you might need to be careful to preserve configuration and other normally-handled-for-you properties, or call a specific target.
This appears to have been added to MSBuild in the dev11 timeframe. @cdmihai went into detail on the process in dotnet/msbuild#2274 (comment). The current team doesn't know why it's necessary. |
Ya, that's what kills your proposed workaround in virtually all my scenarios. That would build the default configuration of the project, which could mean building all the target frameworks in debug mode, which is almost never what I would expect or need. Also, it would cause over-build, compiling twice etc. which can at least slow down the build, but also lead to symbols and DLLs not always matching up. It's a non-starter for me. |
@mhutch came up with an interesting workaround in dotnet/msbuild#2399 (comment): <!-- workaround for https://github.com/Microsoft/msbuild/issues/2399 -->
<Target Name="WorkaroundMSBuildIssue2399" BeforeTargets="GetTargetFrameworkProperties">
<PropertyGroup>
<ReferringTargetFramework>$(TargetFramework)</ReferringTargetFramework>
</PropertyGroup>
</Target> In the referenced project. That essentially disables the target-framework compatibility check for the referenced project, which could be somewhat dangerous (depending on the nature of other references to the project) but avoids this problem. |
WorkaroundSet <AddSyntheticProjectReferencesForSolutionDependencies>false</AddSyntheticProjectReferencesForSolutionDependencies> in the project that has the (Was poking around near this target for another reason and saw this.) |
Moving to msbuild because after the double-evaluation fix, this compatibility check happens there in the context of the caller. |
This issue was moved to dotnet/msbuild#2661 |
It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that the output is incompatible. This commit listens to the preexisting ProjectReference metadatum ReferenceOutputAssembly and avoids the compatibility/best-match checks on ProjectReferences that avoid the dependency. Fixes dotnet#2661 (and dotnet/sdk#939).
It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that the output is incompatible. This commit listens to the preexisting ProjectReference metadatum ReferenceOutputAssembly and avoids the compatibility/best-match checks on ProjectReferences that avoid the dependency. Fixes dotnet#2661 (and dotnet/sdk#939).
It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that the output is incompatible. This commit listens to the preexisting ProjectReference metadatum ReferenceOutputAssembly and avoids the compatibility/best-match checks on ProjectReferences that avoid the dependency. Fixes #2661 (and dotnet/sdk#939).
It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that the output is incompatible. This commit listens to the preexisting ProjectReference metadatum ReferenceOutputAssembly and avoids the compatibility/best-match checks on ProjectReferences that avoid the dependency. Fixes dotnet#2661 (and dotnet/sdk#939).
- aspnet/KoreBuild#143 Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks; dotnet/sdk#939 workarounds fail in this scenario - bump ApiCheck package version Improve project-to-project reference and native assembly handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - catch and ignore `BadImageFormatException` in `AssemblyLoadContext.GetAssemblyName()` - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Fall back to `RuntimeTargets` when `RuntimeAssemblies` yields no assemblies Change ApiCheck.exe's options and output - add `api-check --compact-output` option - generally make tool's output more useful to the task - catch and log `FileNotFoundException`; output types and stack traces of caught `Exception`s - change ApiCheck.exe option from `--ApiListing` to `--api-listing` for consistency w/ other options Use Microsoft.Extensions.CommandLineUtils.Sources package - VersionTool project cannot do this because it has `public` properties of these `internal` types Update appveyor.yml now that VS 2017 RC image is no more nits: - remove `PackageGraph.RuntimeIsCompatible()` `candidateRuntime` parameter - not needed and confusingly-named; passed value included in `compatibleRuntimes` - update solution to use current project type GUID - ignore global.json and launchSettings.json - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj - make a couple of constructors `private`; used only in `public static` methods - ignore case a bit more - remove duplicate `<PropertyGroup>` from `NugetReferenceResolver` project - get this repo building on Linux - don't need API checks in this repo - centralize a few more properties in dependencies.props notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates
With VS2015 projects, I can have a P2P from a portable library to a net46 library by setting metadata on the project reference:
But with the .NET SDK projects, even with this metadata the build fails:
This blocks scenarios where a P2P exists merely for the sake of ensuring build ordering but without the assembly reference. In my particular scenario, the referenced project provides a binary that the build of the portable library picks up for code generation purposes.
The text was updated successfully, but these errors were encountered: