Build for desktop framework on non-windows platforms #335

dasMulli · 2016-10-27T20:50:32Z

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?

The text was updated successfully, but these errors were encountered:

nguerrera · 2016-10-28T20:58:23Z

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 · 2016-10-28T21:29:16Z

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 · 2016-10-28T21:39:58Z

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:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/FrameworkReferenceResolver.cs

Line 33 in c1a276f

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

This should all be in one place.

nguerrera · 2016-10-28T21:56:53Z

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:

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

@rainersigwald @jeffkl What do you think?

eerhardt · 2016-10-28T22:08:08Z

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 · 2016-10-28T22:15:05Z

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 · 2016-10-28T22:28:22Z

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 · 2016-10-28T22:30:39Z

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

dasMulli · 2016-10-28T22:45:27Z

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 · 2016-10-28T22:57:51Z

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

mellinoe · 2016-11-01T00:11:18Z

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 · 2016-11-01T15:00:12Z

@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 · 2016-11-01T16:21:01Z

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 · 2016-12-01T19:50:21Z

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 · 2016-12-04T18:32:15Z

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 · 2016-12-17T08:01:06Z

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

borgdylan · 2016-12-17T09:21:40Z

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

nguerrera · 2016-12-18T01:06:13Z

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

borgdylan · 2016-12-18T08:01:54Z

Thanks, even passing in some magic property would help.

nguerrera · 2016-12-18T18:04:41Z

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 · 2016-12-18T18:22:08Z

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 · 2016-12-18T18:23:04Z

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

alexvaluyskiy · 2016-12-28T18:44:17Z

Any progress here?

borgdylan · 2016-12-28T19:45:41Z

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

dasMulli · 2017-01-08T22:58:02Z

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>

alastairs · 2018-10-05T16:48:55Z

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 · 2018-10-13T13:47:57Z

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 · 2018-10-15T14:20:47Z

@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 · 2018-11-10T05:52:56Z

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?

JoseFMP · 2018-11-15T05:22:08Z

I am also interested to know. It has been a while since this issue is around. Wondering if any solutions are available in the meantime.

… ongoing issue, see: dotnet/sdk#335

Without a targeting pack running dotnet build on a mac/ubuntu will fail with a "Reference assemblies were not found".Adding these targeting pack will allow happy roundtripping between windows and mac or ubuntu. See dotnet/sdk#335 for more details

- Removed Fake build, using Cake instead - Removed unused install.ps1 for MtHost - Organize all Samples into a subdirectory - Organize common properties into common.props and signing.props - Update readme.md with nuget package links - Support Appveyor build on ubuntu and windows - Ubuntu builds will only run tests on netcore/netstandard and to support this added netfx.props to projects as described [here](dotnet/sdk#335 (comment)) - windows tests run on full framework + netstandard

RehanSaeed · 2019-06-01T15:31:46Z

@dsyme's solution (slightly modified below) seems to work perfectly on Ubuntu and Mac using Azure DevOps.

<PropertyGroup Label="Build net4xx on Mono" Condition="$(TargetFramework.StartsWith('net4')) and '$(OS)' == 'Unix'">
    <!-- See https://www.cafe-encounter.net/p2312/multi-targetting-net-framework-and-net-core-in-a-single-project -->
    <!-- When compiling .NET Core SDK 2.0 projects targeting .NET 4.x.x on Mono using 'dotnet build' you have to -->
    <!-- tell MSBuild where the Mono copy of the reference assemblies is. Looks in the standard install locations. -->
    <BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/Library/Frameworks/Mono.framework/Versions/Current/lib/mono')">/Library/Frameworks/Mono.framework/Versions/Current/lib/mono</BaseFrameworkPathOverrideForMono>
    <BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/usr/lib/mono')">/usr/lib/mono</BaseFrameworkPathOverrideForMono>
    <BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/usr/local/lib/mono')">/usr/local/lib/mono</BaseFrameworkPathOverrideForMono>
    <!-- If we found Mono reference assemblies, then use them. -->
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net40'">$(BaseFrameworkPathOverrideForMono)/4.0-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net45'">$(BaseFrameworkPathOverrideForMono)/4.5-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net451'">$(BaseFrameworkPathOverrideForMono)/4.5.1-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net452'">$(BaseFrameworkPathOverrideForMono)/4.5.2-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net46'">$(BaseFrameworkPathOverrideForMono)/4.6-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net461'">$(BaseFrameworkPathOverrideForMono)/4.6.1-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net462'">$(BaseFrameworkPathOverrideForMono)/4.6.2-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net47'">$(BaseFrameworkPathOverrideForMono)/4.7-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net471'">$(BaseFrameworkPathOverrideForMono)/4.7.1-api</FrameworkPathOverride>
    <FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net472'">$(BaseFrameworkPathOverrideForMono)/4.7.2-api</FrameworkPathOverride>
    <EnableFrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">true</EnableFrameworkPathOverride>
    <!-- Add the Facades directory. Not sure how else to do this. Necessary at least for .NET 4.5 -->
    <AssemblySearchPaths Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">$(FrameworkPathOverride)/Facades;$(AssemblySearchPaths)</AssemblySearchPaths>
</PropertyGroup>

However, this does not work with net472 on a Mac. Ubuntu seems to work fine for some reason.

nguerrera · 2019-06-01T20:46:08Z

The path forward here is dotnet/designs#33 (comment)

Please try those packages. We will not be investigating issues with workarounds like above.

YairHalberstadt · 2019-09-11T09:10:56Z

Based on dotnet/designs#33 (comment), All I had to do was add

  <ItemGroup>
    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies"
                      Version="1.0.0-preview.2"
                      PrivateAssets="All" />
  </ItemGroup>

To the csproj I was trying to build, and everything worked!

dsplaisted · 2019-12-05T20:59:34Z

The 1.0.0 versions of the reference assembly packages are now available. I'm going to close this issue, and I've created #4009 to track the further work of referencing these packages automatically.

…d-by: Vlada Shubina <[email protected]> * initial release notes for v4 to track as we go * added dotnet#320 --------- Co-authored-by: Vlada Shubina <[email protected]>

Workaround dotnet/sdk#335

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

nguerrera self-assigned this Oct 28, 2016

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

dasMulli mentioned this issue Nov 21, 2016

Cannot target mono i.e. full framework on Linux dotnet/msbuild#1360

Closed

srivatsn added the Bug label Jan 19, 2017

livarcocc added this to the 3.0.1xx milestone Sep 25, 2018

kkm000 mentioned this issue Oct 8, 2018

Integrate Grpc.Tools into msbuild system (C# only) grpc/grpc#13207

Merged

gheibia mentioned this issue Oct 26, 2018

Unable to load .NET 4.6 project in VS Code / Mac even with mono-mdk and stable mono installed dotnet/vscode-csharp#2383

Closed

roji mentioned this issue Nov 7, 2018

Disable net461 build on non-Windows platforms dotnet/efcore#13917

Closed

This was referenced Dec 21, 2018

Enable cross platform compilation of the solution. SteeltoeOSS/Common#7

Merged

Enable cross platform compilation of the solution. SteeltoeOSS/Management#31

Merged

andygjp added a commit to andygjp/ExpressionToSql that referenced this issue Dec 30, 2018

chore: workaround for multiple target frameworks on linux. This is an…

e44e098

… ongoing issue, see: dotnet/sdk#335

sharwell mentioned this issue Jan 17, 2019

Improve build tasks packaging coverlet-coverage/coverlet#299

Merged

4 tasks

maldworth mentioned this issue Jan 18, 2019

Use Cake Build MassTransit/MassTransit#1297

Merged

andreasplesch mentioned this issue Apr 23, 2019

Errors While Building on Linux KhronosGroup/UnityGLTF#195

Closed

jindraivanek mentioned this issue Jun 13, 2019

Use Microsoft.NETFramework.ReferenceAssemblies package for reference assemblies paths on mono fsprojects/fantomas#444

Merged

TheAngryByrd mentioned this issue Sep 11, 2019

Consider replacing netfx.props with Microsoft.NETFramework.ReferenceAssemblies package TheAngryByrd/MiniScaffold#140

Closed

kekekeks mentioned this issue Sep 11, 2019

Replace NetFX.props hacks with Microsoft.NETFramework.ReferenceAssemblies AvaloniaUI/Avalonia#2966

Closed

wallymathieu mentioned this issue Sep 28, 2019

Good to know when on *nix wallymathieu/assertfail#47

Closed

dsplaisted mentioned this issue Dec 5, 2019

Automatically reference .NET Framework reference assembly packages if needed #4009

Closed

dsplaisted closed this as completed Mar 12, 2020

OsirisTerje mentioned this issue Jul 6, 2023

Question: Nunit3 with Mono under Ubuntu nunit/nunit#4412

Closed

busgaidw2 added a commit to busgaidw2/CommandLineUtils that referenced this issue Aug 6, 2024

Add package reference to .NET Framework ref assemblies for x-plat work

fb48799

Workaround dotnet/sdk#335

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build for desktop framework on non-windows platforms #335

Build for desktop framework on non-windows platforms #335

dasMulli commented Oct 27, 2016

nguerrera commented Oct 28, 2016

eerhardt commented Oct 28, 2016

nguerrera commented Oct 28, 2016

nguerrera commented Oct 28, 2016

eerhardt commented Oct 28, 2016

nguerrera commented Oct 28, 2016

eerhardt commented Oct 28, 2016

nguerrera commented Oct 28, 2016

dasMulli commented Oct 28, 2016 •

edited

Loading

nguerrera commented Oct 28, 2016

mellinoe commented Nov 1, 2016

rainersigwald commented Nov 1, 2016

nguerrera commented Nov 1, 2016

borgdylan commented Dec 1, 2016

gulbanana commented Dec 4, 2016

borgdylan commented Dec 17, 2016

borgdylan commented Dec 17, 2016 •

edited

Loading

nguerrera commented Dec 18, 2016

borgdylan commented Dec 18, 2016

nguerrera commented Dec 18, 2016

borgdylan commented Dec 18, 2016

borgdylan commented Dec 18, 2016

alexvaluyskiy commented Dec 28, 2016

borgdylan commented Dec 28, 2016

dasMulli commented Jan 8, 2017 •

edited

Loading

alastairs commented Oct 5, 2018 •

edited

Loading

gaviriar commented Oct 13, 2018 •

edited

Loading

dasMulli commented Oct 15, 2018

aggieben commented Nov 10, 2018 •

edited

Loading

JoseFMP commented Nov 15, 2018

RehanSaeed commented Jun 1, 2019 •

edited

Loading

nguerrera commented Jun 1, 2019

YairHalberstadt commented Sep 11, 2019 •

edited

Loading

dsplaisted commented Dec 5, 2019

Build for desktop framework on non-windows platforms #335

Build for desktop framework on non-windows platforms #335

Comments

dasMulli commented Oct 27, 2016

nguerrera commented Oct 28, 2016

eerhardt commented Oct 28, 2016

nguerrera commented Oct 28, 2016

nguerrera commented Oct 28, 2016

eerhardt commented Oct 28, 2016

nguerrera commented Oct 28, 2016

eerhardt commented Oct 28, 2016

nguerrera commented Oct 28, 2016

dasMulli commented Oct 28, 2016 • edited Loading

nguerrera commented Oct 28, 2016

mellinoe commented Nov 1, 2016

rainersigwald commented Nov 1, 2016

nguerrera commented Nov 1, 2016

borgdylan commented Dec 1, 2016

gulbanana commented Dec 4, 2016

borgdylan commented Dec 17, 2016

borgdylan commented Dec 17, 2016 • edited Loading

nguerrera commented Dec 18, 2016

borgdylan commented Dec 18, 2016

nguerrera commented Dec 18, 2016

borgdylan commented Dec 18, 2016

borgdylan commented Dec 18, 2016

alexvaluyskiy commented Dec 28, 2016

borgdylan commented Dec 28, 2016

dasMulli commented Jan 8, 2017 • edited Loading

alastairs commented Oct 5, 2018 • edited Loading

gaviriar commented Oct 13, 2018 • edited Loading

dasMulli commented Oct 15, 2018

aggieben commented Nov 10, 2018 • edited Loading

JoseFMP commented Nov 15, 2018

RehanSaeed commented Jun 1, 2019 • edited Loading

nguerrera commented Jun 1, 2019

YairHalberstadt commented Sep 11, 2019 • edited Loading

dsplaisted commented Dec 5, 2019

dasMulli commented Oct 28, 2016 •

edited

Loading

borgdylan commented Dec 17, 2016 •

edited

Loading

dasMulli commented Jan 8, 2017 •

edited

Loading

alastairs commented Oct 5, 2018 •

edited

Loading

gaviriar commented Oct 13, 2018 •

edited

Loading

aggieben commented Nov 10, 2018 •

edited

Loading

RehanSaeed commented Jun 1, 2019 •

edited

Loading

YairHalberstadt commented Sep 11, 2019 •

edited

Loading