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

Build for desktop framework on non-windows platforms #335

Open
dasMulli opened this Issue Oct 27, 2016 · 133 comments

Comments

Projects
None yet
@dasMulli
Contributor

dasMulli commented Oct 27, 2016

The dotnet CLI allowed to build net* targets on mac and linux using the reference assemblies installed with mono. It seems this is not supported by the targets in Microsoft.NET.Sdk. For fun, I also tried referencing the targeting pack NuGets which also didn't work.

Is there a plan for bringing back support for building net* projects on linux/mac? Or should it already work?

@nguerrera

This comment has been minimized.

Member

nguerrera commented Oct 28, 2016

We would like this to work, but haven't had the time yet to invest in it.

I would prefer that msbuild common targets could resolve the mono targeting pack directory, rather than special work in the SDK to locate it.

@eerhardt

This comment has been minimized.

Member

eerhardt commented Oct 28, 2016

Here's the current code that resolves the Mono reference assemblies:

https://github.com/dotnet/core-setup/blob/master/src/Microsoft.Extensions.DependencyModel/Resolution/DotNetReferenceAssembliesPathResolver.cs

Someone (dotnet/SDK or core MSBuild) could call into this code to get the path. (There is also an environment variable available to override the path).

@nguerrera

This comment has been minimized.

Member

nguerrera commented Oct 28, 2016

Aside: That class has a super general name, no docs, and only actually finds the directory on non-Windows.

I think there should be a root reference assembly directory resolved by msbuild that works on all platforms, and we should use that throughout. It is super strange to me that when we call this, we then have to handle windows separately:

var programFiles = Environment.GetEnvironmentVariable("ProgramFiles(x86)");

This should all be in one place.

@nguerrera nguerrera changed the title from Q: Build for desktop framework on non-windows platforms to Build for desktop framework on non-windows platforms Oct 28, 2016

@nguerrera

This comment has been minimized.

Member

nguerrera commented Oct 28, 2016

So it looks like msbuild already has $(TargetFrameworkRootPath) which the user can override (but we wouldn't respect). However, it seems to not set it to non-empty when the task uses a default value.

Here's how I'd like things to work:

  1. MSBuild can also find Mono's xbuild-framework dir on non-Windows and use that as $(TargetFrameworkRootPath) without user intervention.
  2. MSBuild sets $(TargetFrameworkRootPath) when it uses a default location on any platform.
  3. SDK uses $(TargetFrameworkRootPath) anywhere it needs this path outside of what RAR does for us.

@rainersigwald @jeffkl What do you think?

@nguerrera nguerrera self-assigned this Oct 28, 2016

@nguerrera nguerrera added this to the 1.0 RTM milestone Oct 28, 2016

@eerhardt

This comment has been minimized.

Member

eerhardt commented Oct 28, 2016

Agreed that ALL the logic should exist in one place.

Another aside here is that this code needs to run/work at runtime of the app because things like ASP.NET MVC Razor View compilation needs to find these assemblies.

That's the reason at least part of this code (the non-windows part) is contained in DependencyModel - which is used both at build and run time.

@nguerrera

This comment has been minimized.

Member

nguerrera commented Oct 28, 2016

If msbuild can safely take a dependency on the same thing that finds it at runtime, then we can truly have only one place.

Regardless of duplication, though, everything running in the build to resolve this directory the same way GetReferenceAssemblyPaths does. Otherwise, there's a mismatch where RAR can respect $(TargetFrameworkRootPath) set by user, but other code in the SDK cannot, etc.

@eerhardt

This comment has been minimized.

Member

eerhardt commented Oct 28, 2016

Maybe the most appropriate thing to do here is for the tooling (MSBuild, SDK, etc) to write the location into the .deps.json file during "build" so it can be used by "run". The DependencyModel can use that value as one more place to look for ref assemblies.

During "publish" the value wouldn't get written into the .deps.json file because the ref assemblies get copied to the "refs" folder. Thus a published app doesn't need to get the location Reference Assemlies folder, since it won't exist on the end-users machine.

@nguerrera

This comment has been minimized.

Member

nguerrera commented Oct 28, 2016

@eerhardt That sounds like the right place to land indeed.

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Oct 28, 2016

Wouldn't it be simpler - from a end-user perspective - to pull the complete set of reference assemblies as a NuGet package? Similar to referencing Microsoft.NETCore.App..
dotnet run and dotnet test would still have to figure out where the mono executable is but just building an application would not rely on a system-wide install of another component. That way using a docker container with just the CLI installed would be enough to produce a runnable output.

@nguerrera

This comment has been minimized.

Member

nguerrera commented Oct 28, 2016

We have talked informally about having classic targeting packs available as nuget packages before. @terrajobst, any plans there?

@mellinoe

This comment has been minimized.

mellinoe commented Nov 1, 2016

We've had https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.TargetingPack.NETFramework.v4.6.2 (and other .NET framework versions) for a while, but they're only used for internal builds and aren't published to nuget.org. I think they contain the same assemblies as the real targeting pack.

@rainersigwald

This comment has been minimized.

Contributor

rainersigwald commented Nov 1, 2016

@mellinoe IIRC I tried to use those (for a different, internal project) and they were missing some key parts.

I once talked about this offline with @akoeplinger, but didn't reach a conclusion.

MSBuild on .NET Core doesn't support finding references in all the same ways we do on Mono/Desktop framework. Most relevant is probably GAC resolution, but targeting packs are also important. As mentioned above, those should be nugetizable--in which case you could probably get stuff built pretty well. There are some other task differences though (GenerateResources springs to mind with the different possibilities of embedding for .NET Core and desktop).

The deps-file approach for run does seem reasonable to me too (given the current CLI run behavior).

@nguerrera

This comment has been minimized.

Member

nguerrera commented Nov 1, 2016

I don't care at all about GAC resolution. If your build depends on it, it's busted as far as I'm concerned. We never should have gone to the GAC for compilation references. I've removed GAC from the default RAR search paths in the SDK.

Targeting packs via nuget would certainly be nice, but do we need to block on it? What's the harm in probing for xbuild-frameworks?

As far as other differences (GenerateResources), we should distinguish between what are temporary gaps and what is fundamentally never going to work on Core.

@borgdylan

This comment has been minimized.

borgdylan commented Dec 1, 2016

I hope that this gets resolved by RTM. Currently this makes the csproj variant of the .NET CLI a non-starter for most of my projects.

@gulbanana

This comment has been minimized.

gulbanana commented Dec 4, 2016

this feature would allow roundtripping projects between vs and vs4mac. right now, you can't do that if they have TargetFrameworks like net461;netcoreapp1.0

@borgdylan

This comment has been minimized.

borgdylan commented Dec 17, 2016

Has this been worked on for preview 4 of the CLI?

@borgdylan

This comment has been minimized.

borgdylan commented Dec 17, 2016

After checking I confirm that this is still an issue with preview 4. Are there any known workarounds?

@nguerrera

This comment has been minimized.

Member

nguerrera commented Dec 18, 2016

I'm taking a look at doing something simple to unblock this.

@borgdylan

This comment has been minimized.

borgdylan commented Dec 18, 2016

Thanks, even passing in some magic property would help.

@nguerrera

This comment has been minimized.

Member

nguerrera commented Dec 18, 2016

So as a workaround, explicitly passing/setting TargetFrameworkRootPath with path to xbuild-frameworks (e.g. /p:TargetFrameworkRootPath=/usr/lib/mono/xbuild-frameworks) should work, but doesn't.

The issue is that the mono redist list files have a redirect of the TargetFrameworkDirectory to somewhere else. msbuild understands this redirect, but currently only if it's actually running on Mono:

https://github.com/Microsoft/msbuild/blob/cb8c727a898e4439a3cd18f329504e436b0b7c00/src/Utilities/ToolLocationHelper.cs#L3106-L3111

:(

@borgdylan

This comment has been minimized.

borgdylan commented Dec 18, 2016

I did try that workaround and it did not work as you mentioned. Mono happens to redirect 4.6.x down to 4.5 to the 4.0 directory for example. It also does not list all the assemblies, relying on the automatic selection of all assemblies in the specified directory instead.

@borgdylan

This comment has been minimized.

borgdylan commented Dec 18, 2016

Can we open an issue against msbuild to have the behaviour change? Or have they mentioned that this will not change?

@alexvaluyskiy

This comment has been minimized.

alexvaluyskiy commented Dec 28, 2016

Any progress here?

@borgdylan

This comment has been minimized.

borgdylan commented Dec 28, 2016

I asked on the msbuild repo but no one answered so far.

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Jan 8, 2017

fyi I've had success using the targeting pack nuget (adding the dotnet-core feed to my NuGet.Config). Not using this for production though but.. works on my machine ™️
This works with the latest source build of the cli:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp1.0;net461</TargetFrameworks>
    <RuntimeIdentifiers>osx.10.11-x64;win7-x64</RuntimeIdentifiers>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
    <FrameworkPathOverride>$(NuGetPackageRoot)microsoft.targetingpack.netframework.v4.6.1\1.0.1\lib\net461\</FrameworkPathOverride>
  </PropertyGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <PackageReference Include="Microsoft.TargetingPack.NETFramework.v4.6.1" Version="1.0.1" ExcludeAssets="All" PrivateAssets="All" />
  </ItemGroup>
</Project>
@livarcocc

This comment has been minimized.

Member

livarcocc commented May 25, 2018

@dsplaisted can you give us an ETA for this?

@AArnott

This comment has been minimized.

Contributor

AArnott commented Jun 6, 2018

I'd also like to submit a request for portable-* TxM's. Yes, some packages (still) have popularity in PCL profiles. I can build them on Windows in .NET SDK projects using @onovotny's MSBuildSdkExtras, so whether with or without that package I don't care, but I'd like to be able to build those packages on linux too.

@eerhardt

This comment has been minimized.

Member

eerhardt commented Jun 6, 2018

@AArnott - I think you may get more visibility requesting PCL support on dotnet/designs#33. I'm not sure if you are aware of that document, but that's the design/requirements doc that will enable fixing this current issue (#335).

@prochnowc

This comment has been minimized.

prochnowc commented Jul 3, 2018

Did anyone get the workaround applied by the F# team to work onAppVeyor linux builds? dotnet build cannot find framework assemblies even when adjusting FrameworkPathOverride.

/usr/share/dotnet/sdk/2.1.300/Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

@dsyme

This comment has been minimized.

dsyme commented Jul 3, 2018

@prochnowc Do you have mono installed on the AppVeyor machine?

@prochnowc

This comment has been minimized.

prochnowc commented Jul 3, 2018

@prochnowc

This comment has been minimized.

prochnowc commented Jul 3, 2018

I've setup clean VM with same Ubuntu, Monto and .NET Core SDK. When expirementing i noticed that by default the AssemblySearchPaths is set to {CandidateAssemblyFiles};{HintPathFromItem};{TargetFrameworkDirectory};{RawFileName}.

I changed the value provided by the F# team from <AssemblySearchPaths Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">$(FrameworkPathOverride)/Facades;$(AssemblySearchPaths)</AssemblySearchPaths>
to
<AssemblySearchPaths Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">$(FrameworkPathOverride);$(FrameworkPathOverride)/Facades;{CandidateAssemblyFiles};{HintPathFromItem};{RawFileName}</AssemblySearchPaths>

Now it seems it can compile (at least in my own Ubuntu VM).

@Miggleness

This comment has been minimized.

Miggleness commented Aug 3, 2018

What's the guidance for targeting net framework 4.5 and up on non-Windows platform? Using targeting packs did work for me, but the targeting pack packages are still non-searchable in Nuget despite being around for 2-3 years.

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Aug 3, 2018

Those packages aren’t really meant for public consumption. Personally I recommend using mono to build on *nix

@jskeet

This comment has been minimized.

jskeet commented Aug 3, 2018

@dasMulli: That's really not a great solution in terms of having to install multiple things in CI servers etc. If I'm just building against reference assemblies, there's no logical need for a full-blown Mono installation as well as the .NET Core SDK.

dotnet/designs#33 indicates the way forward, which I think will be much, much more pleasant. (I now see you've been active in that PR anyway.)

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Aug 3, 2018

@jskeet: those packages are missing a few bits, I think someone here ran into it but not sure where it is logged. If the build worksusing the package then great, but i wouldn’t recommend it as a general purpose solution.
Only mono‘s msbuild has the ifdef‘d logic to process mono‘s ref assembly structure.
Yeah I’m the one who logged this issue so been active ever since in this topic ^^

@jskeet

This comment has been minimized.

jskeet commented Aug 3, 2018

I'd go in the other direction - if Mono works for the moment, that's great, but I don't want that to be the long term solution :)

@Miggleness

This comment has been minimized.

Miggleness commented Aug 4, 2018

My objective,and likely most cases of building on non-windows platform, would just like build to work. Not necessarily to deploy the assembly for .net framework. Good to see the first option is to go with reference targeting packs.

natemcmaster added a commit to natemcmaster/CommandLineUtils that referenced this issue Aug 15, 2018

@TheAngryByrd TheAngryByrd referenced this issue Aug 20, 2018

Closed

Better FrameworkPathOverride #99

0 of 6 tasks complete
@wadewegner

This comment has been minimized.

wadewegner commented Aug 22, 2018

I was able to target both netstandard2.0 and net452 by using FrameworkPathOverride and including microsoft.targetingpack.netframework.v4.5.2 from myget. Appears to be working quite well for me on MacOS.

https://gist.github.com/wadewegner/a66af31149d279757357b05deb6c032c

@livarcocc livarcocc modified the milestones: 2.3.0, 3.0.1xx Sep 25, 2018

@alastairs

This comment has been minimized.

alastairs commented Oct 5, 2018

I tried out a slightly modified form of @wadewegner's Gist for net471, but I found that I had to include a line <Reference Include="netstandard"> in order for build to succeed (the application depends on libraries which only target netstandard2.0). However, when I came to run the application within its Docker container, it crashed with the following exception:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. File not found. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. File not found.

I've probably missed something, but I can't really tell what from this output. Do I need to, e.g., copy the Targeting Pack assemblies to the publish folder, or make my libraries target net471 too? System.Runtime doesn't appear in the publish folder right now.

@gaviriar

This comment has been minimized.

gaviriar commented Oct 13, 2018

Hi there, I also updated my project like the example by @dasMulli but for net472.

My build throws a couple of warnings and the error at the end that mscorlib.dll could not be found:

/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Data". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Drawing". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Xml". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Core". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Runtime.Serialization". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Xml.Linq". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Numerics". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.IO.Compression.FileSystem". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.CSharp". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Configuration". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.IO.Compression". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.ServiceModel". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
/usr/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Transactions". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [/home/gaviriar/net_compile/net_compile.csproj]
CSC : error CS0006: Metadata file '/mscorlib.dll' could not be found [/home/gaviriar/net_compile/net_compile.csproj]

Upon some investigation, and searching through the .nuget/packages:

find /home/gaviriar/.nuget/ -name "*mscorlib.dll"
/home/gaviriar/.nuget/packages/microsoft.netcore.app/2.0.0/ref/netcoreapp2.0/mscorlib.dll
/home/gaviriar/.nuget/packages/microsoft.netcore.app/2.1.3/ref/netcoreapp2.1/mscorlib.dll
/home/gaviriar/.nuget/packages/microsoft.targetingpack.netframework.v4.7.1/1.0.0/lib/net471/mscorlib.dll
/home/gaviriar/.nuget/packages/netstandard.library/2.0.2/build/netstandard2.0/ref/mscorlib.dll
/home/gaviriar/.nuget/packages/netstandard.library/2.0.0/build/netstandard2.0/ref/mscorlib.dll
/home/gaviriar/.nuget/packages/microsoft.targetingpack.netframework.v4.5.1/1.0.1/lib/net451/mscorlib.dll
/home/gaviriar/.nuget/packages/microsoft.targetingpack.netframework.v4.6.1/1.0.1/lib/net461/mscorlib.dll
/home/gaviriar/.nuget/packages/microsoft.targetingpack.netframework.v4.5.2/1.0.1/lib/net452/mscorlib.dll
/home/gaviriar/.nuget/packages/runtime.win-x64.microsoft.netcore.app/2.0.0/runtimes/win-x64/lib/netcoreapp2.0/mscorlib.dll
/home/gaviriar/.nuget/packages/runtime.win-x64.microsoft.netcore.app/2.1.0/runtimes/win-x64/lib/netcoreapp2.1/mscorlib.dll
/home/gaviriar/.nuget/packages/runtime.win-x64.microsoft.netcore.app/2.1.3/runtimes/win-x64/lib/netcoreapp2.1/mscorlib.dll
/home/gaviriar/.nuget/packages/runtime.linux-x64.microsoft.netcore.app/2.0.0/runtimes/linux-x64/lib/netcoreapp2.0/mscorlib.dll
/home/gaviriar/.nuget/packages/runtime.linux-x64.microsoft.netcore.app/2.1.0/runtimes/linux-x64/lib/netcoreapp2.1/mscorlib.dll
/home/gaviriar/.nuget/packages/runtime.linux-x64.microsoft.netcore.app/2.1.3/runtimes/linux-x64/lib/netcoreapp2.1/mscorlib.dll

It seems like the mscorlib.dll file is missing in the net472 targeting packs. Unfortunately, I need to target net472 and cannot use anything lower. How should I go about requesting an update of this package (if even possible)?

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Oct 15, 2018

@gaviriar I think something is a bit off in your project file for this workaround, just tested building for 4.7.2 using:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp2.1;net472</TargetFrameworks>
    <RestoreAdditionalProjectSources>$(RestoreAdditionalProjectSources);https://dotnet.myget.org/F/dotnet-core/api/v3/index.json</RestoreAdditionalProjectSources>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(TargetFramework)' == 'net472' ">
    <FrameworkPathOverride>$(PkgMicrosoft_TargetingPack_NETFramework_v4_7_2)\lib\net472\</FrameworkPathOverride>
  </PropertyGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net472' ">
    <PackageReference Include="Microsoft.TargetingPack.NETFramework.v4.7.2" Version="1.0.0" ExcludeAssets="All" PrivateAssets="All" GeneratePathProperty="true" />
  </ItemGroup>
</Project>

Note that the GeneratePathProperty metadata on PackageReference is only available in VS 15.9 / CLI 2.1.500+ (previews).

@aggieben

This comment has been minimized.

aggieben commented Nov 10, 2018

This technique doesn't seem to work right for me, quite (on macOS):

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net461;netstandard2.0</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)' == 'net461'">
    <FrameworkPathOverride>$(NuGetPackageRoot)microsoft.targetingpack.netframework.v4.6.1\1.0.1\lib\net461\</FrameworkPathOverride>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'net461'">
    <PackageReference Include="Microsoft.TargetingPack.NETFramework.v4.6.1" Version="1.0.1" />
  </ItemGroup>
</Project>

The top of the stack of errors:

/usr/local/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): error MSB4018: The "ResolveAssemblyReference" task failed unexpectedly. [/Users/ben/proj/oss/true-myth-csharp/src/TrueMyth/TrueMyth.csproj]
/usr/local/share/dotnet/sdk/2.1.403/Microsoft.Common.CurrentVersion.targets(2110,5): error MSB4018: System.InvalidOperationException: Metadata image doesn't represent an assembly. [/Users/ben/proj/oss/true-myth-csharp/src/TrueMyth/TrueMyth.csproj]

Maybe has something changed since this workaround was first suggested? Is my path override incorrect?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment