-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Project references not always copied even when Private is transitively set to True #1845
Comments
btw, I was testing this sample today and I've noticed that the transitive dependencies are only copied if there is a symbolic reference from a direct dependency. However, if you comment that line (or declare it as a different type like an interface or System.Object) then Lib3 ends up with Lib3 and Lib1.dll. Lib0.dll doesn't get copied. I've find this behaviour particularly confusing. It makes it impossible to predict what dependencies are copied by simply looking at dependencies in the project file |
@sebastianslutzky This is why I've included symbolic references for each project reference. I just didn't want to mix different issues. |
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845 (cherry picked from commit 8af44c5)
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845 (cherry picked from commit 8af44c5)
I've hit this as well. Thanks for the workaround! |
Overview
Take the following solution, with emphasis on references:
Solid lines denote project references with
Private
set toTrue
.Dashed lines denote project references with
Private
set toFalse
.Dash-dot lines denote project references with
Private
undefined.Issue
With MSBuild 14.0,
ClassLibrary0
is not copied toConsoleApplication6
's output directory.This is consistent for builds from inside Visual Studio 2015, as well as from the command line.
Analysis
Using Kirill Osenkovs MSBuild Structured Log Viewer.
In the build of
ConsoleApplication6
, MSBuild realizes it needsClassLibrary0
. However, for whatever reasons it cannot find the reference:A partial insight is given by this message when building
ClassLibrary2
.We now understand and accept that
ClassLibrary0
won't be copied toClassLibarary2
.Note that this means that the
Private
flag is actually tri-state, which can be quite a surprise for Visual Studio users acustomed to the booleanCopy Local
property.However, this doesn't explain why
ClassLibrary0
is not copied toConsoleApplication6
, since there is a complete chain of project references havingPrivate
set toTrue
straight fromConsoleApplication6
toClassLibrary0
.Work-Around
From the analysis, it's quite easy to fix the issue:
Set
Private = True
for the project reference fromClassLibrary2
toClassLibrary1
.The text was updated successfully, but these errors were encountered: