Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Ref references need to not be copy local #1895
Trying to build a netstandard application using msbuild, FAKE and paket (yes, it seems it's doable, and not even that hard), I've run into the problem that reference assemblies are being copied to the output directory, which blows up at runtime (when the reference assemblies are loaded, you get an error saying this is a reference assembly basically).
Oh, and if it's not clear, what I'm calling reference assemblies is anything found in a nuget package under the "ref" folder (as opposed to the "lib" folder).
Add System.Runtime as a dependency.
The ref package should be added as Private: false (Copy local: false, my limited understanding of MSBuild has lead me to believe that these are the same).
<When Condition="$(TargetFrameworkIdentifier) == '.NETStandard' And $(TargetFrameworkVersion) == 'v1.5'"> <ItemGroup> <Reference Include="System.Runtime"> <HintPath>..\..\packages\System.Runtime\ref\netstandard1.5\System.Runtime.dll</HintPath> <Private>False</Private> <Paket>True</Paket> </Reference> </ItemGroup> </When>
It's added such that it's copied to the output directory.
<When Condition="$(TargetFrameworkIdentifier) == '.NETStandard' And $(TargetFrameworkVersion) == 'v1.5'"> <ItemGroup> <Reference Include="System.Runtime"> <HintPath>..\..\packages\System.Runtime\ref\netstandard1.5\System.Runtime.dll</HintPath> <Private>True</Private> <Paket>True</Paket> </Reference> </ItemGroup> </When>
Manually fix msbuild file every time you do
added a commit
Aug 29, 2016
For now this is the correct thing to do. In the future I think we need to analyse the
It doesn't matter for now as nobody is using fsproj to compile for netcoreapp and it's not recommended either. Exception is the new FAKE which is compiling scripts for netcoreapp and therefore needs this information :(
@matthid Actually, that's exactly what I was doing. I did a full day of experimenting to see if I could compile to .NETStandard using regular fsc, fake, msbuild and paket, just by slightly modifying the fsproj files. And it worked. I managed to produce dlls that were .NETStandard 1.3, meaning they should (in theory) run on .NET Core and .NET regular. The tests failed spectacularly though, cause paket was copying ref-assemblies and xunit was loading them (cause local dir has precedence over framework it would seem). Thus it blew up, and I made this issue.
As per my understanding, anything in the
@forki what we do right now is not enough as we need to parse runtime.json and handle the runtime tree. For example if runtime.json says that 'run-a' includes 'run-b' we need to copy files from the 'run-b' folder to the output, even when we compile for 'run-a'. the runtime.json specifies the dependency tree.
for example 'win7-x64' includes 'win-x64' includes 'win' ... but we should threat the strings as black boxes, see https://docs.microsoft.com/en-us/dotnet/articles/core/rid-catalog
@Alxandr It only matters if you want to produce and run a netcoreapp application which should run on itself... For a netstandard library and simple usage of it we don't need that...
Note that my analysis might be wrong so please correct me in that case...
This change seems to create another issue.
Moreover we can't override it using
let privateSettings = if relativePath.Contains @"\ref\" then "False" elif copyLocal then "True" else "False"
@matthid It's look that the files are exactly the same
PS P:\> cd O:\System.ComponentModel.TypeConverter.4.1.0\lib\net45 PS O:\System.ComponentModel.TypeConverter.4.1.0\lib\net45> Get-FileHash -Path .\System.ComponentModel.TypeConverter.dll Algorithm Hash Path --------- ---- ---- SHA256 0AD6A7017A54D99E102C17F40EA45D312AAEED96664EA5FF6DE1755BD4F6C6FD O:\System.ComponentModel.Type... PS O:\System.ComponentModel.TypeConverter.4.1.0\ref\net45> Get-FileHash -Path .\System.ComponentModel.TypeConverter.dll Algorithm Hash Path --------- ---- ---- SHA256 0AD6A7017A54D99E102C17F40EA45D312AAEED96664EA5FF6DE1755BD4F6C6FD O:\System.ComponentModel.Type...
I think copying the binary from the