Skip to content
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

Cannot find reference assemblies for .NET 3.5 or lower using core msbuild #1333

Open
nguerrera opened this Issue Nov 10, 2016 · 34 comments

Comments

Projects
None yet
@nguerrera
Copy link
Member

nguerrera commented Nov 10, 2016

dotnet/sdk supports targeting .NET 3.5 just fine if you use desktop msbuild, but it fails to find the reference assemblies using core msbuild. Both desktop and core work fine for NET4.0+.

Steps to reproduce

Create a new project with dotnet new
Change the TargetFramework to net35 or lower
Add <RuntimeIdentifier>win10-x64</RuntimeIdentifier> to the .csproj
dotnet restore
dotnet build

I've been seeing this issue since the move to msbuild. Targeting .NET 3.5 and lower works in the Preview 2 release SDK. All the relevant targeting packs are installed.

Expected behavior

A successful build

Actual behavior

Fails with the error:
... error MSB3644: The reference assemblies for framework ".NETFramework,Version=v3.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. ...

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
Version: 1.0.0-preview3-004056
Commit SHA-1 hash: ccc4968bc3

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64

Moved from dotnet/cli#4626 for @Thealexbarney.

Moved from dotnet/sdk#369 for @piotrpMSFT

@rainersigwald

@dsplaisted

This comment has been minimized.

Copy link
Member

dsplaisted commented Nov 11, 2016

I think the problem is that there aren't any reference assemblies for .NET Framework 3.5. The only thing in my .NETFramework\3.5 reference assemblies folder is Profile\Client. When I target .NET 3.5 from a Class Library, the references are coming from C:\Windows\Microsoft.NET\Framework\v2.0.50727\.

@rainersigwald

This comment has been minimized.

Copy link
Contributor

rainersigwald commented Nov 16, 2016

This comes down to code in FrameworkLocationHelper.GetPathToDotNetFramework that is disabled on .NET Core:

#if !FEATURE_INSTALLED_MSBUILD
return null;
#else

There are some (probably avoidable) registry calls there, but the biggest obstacle seems to be that finding the v3.5 (or whatever) runtime depends on locating the current runtime (Path.GetDirectoryName(typeof(object).Module.FullyQualifiedName)) and looking around it to find the desired version of the framework. That won't work on Core where object comes from somewhere else entirely.

There may be another way to locate a framework (looks like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5 has an InstallPath value that looks promising) but we'd have to figure out the right mechanism (and test the heck out of it).

@KevinH-MS

This comment has been minimized.

Copy link

KevinH-MS commented Feb 15, 2017

What's the work-around for people who need to build such projects on VS 2017? I just ran into this today, and the only thing I could figure out was to compile on a separate machine with only VS 2015 installed.

@rainersigwald

This comment has been minimized.

Copy link
Contributor

rainersigwald commented Feb 15, 2017

@KevinH-MS It sounds like you're seeing something different from this issue--as originally reported, projects build fine using MSBuild.exe. Can you describe your problem in more detail?

@KevinH-MS

This comment has been minimized.

Copy link

KevinH-MS commented Feb 15, 2017

I see. I think that's the answer to my question... 😄

(don't use dotnet build -f net35, use msbuild /p:TargetFramework=net35)

@ChrisMcKee

This comment has been minimized.

Copy link

ChrisMcKee commented Mar 1, 2017

Issues a pain when you're trying to generate a multi-target nuget package;
prior to the great cheese moving of 2016 I had no issues building a package that targeted 2/3.5/4/4.5/etc
Is this likely to be sorted in the next few days when VS17s released? Seems ambitious...

Admittedly I'm presuming this is msbuild related as it came with RC4 / VS2017 changes and the issue in the error being thrown is the same as the op (albeit for every version specified).

<PropertyGroup>
      ...  <TargetFrameworks>net20;net35;net40;net45;net451;net452;net462;netstandard1.3;netstandard1.6;netstandard1.6.1;netcoreapp1.1</TargetFrameworks>
    ...

etc https://github.com/BcryptNet/bcrypt.net/blob/master/src/BCrypt.Net/BCrypt.Net.csproj

Hell, it might be that after all these changes and dotnet versions I need to set fire to my PC and start afresh to get things to build 🔥

@Thealexbarney

This comment has been minimized.

Copy link

Thealexbarney commented Mar 1, 2017

Right now the only options I see are:

  1. Stay on the old project.json system. (Can't use VS2017 as an IDE)
  2. Migrate to msbuild and be dependent on the full msbuild. (Can't build with dotnet SDK)
  3. Drop <= net35 support.

I guess legacy support is a lower priority than other things for now.

Ideally (IMO) there would be targeting packs on NuGet for each framework version, making it easier to target .NET Framework from the dotnet SDK.

@ghost

This comment has been minimized.

Copy link

ghost commented Mar 2, 2017

Our use case at work: targeting net20 is important for us as we have to make some of our libraries work on old Windows Server 2003 systems. We can't upgrade them right now. And we don't want to install anything (say, newer .NET framework versions) to avoid risks of breaking the systems.

We love dotnet tooling, but while this issue is not fixed, we'll have to stay on the full msbuild for this use case.

@schotime

This comment has been minimized.

Copy link

schotime commented Mar 15, 2017

Any updates on this issue?

@ChrisMcKee

This comment has been minimized.

Copy link

ChrisMcKee commented Mar 15, 2017

@schotime I've been using RTW since it came out last week and this seems to be resolved.

@Thealexbarney

This comment has been minimized.

Copy link

Thealexbarney commented Mar 15, 2017

@ChrisMcKee In core MSBuild or full MSBuild?

@schotime

This comment has been minimized.

Copy link

schotime commented Mar 15, 2017

It works in vs for me, but not calling dotnet build manually.

@ChrisMcKee

This comment has been minimized.

Copy link

ChrisMcKee commented Mar 15, 2017

@Thealexbarney Windows, so full. I'm not sure you could target .net 2 on non-win platforms as it would lack the required build targets. 2/3.5/4/4.5/4.6 predating it all. You're back in mono-land there.

@drewnoakes

This comment has been minimized.

Copy link
Member

drewnoakes commented Mar 16, 2017

Also seeing this. Can build in VS2017, but dotnet build gives:

MSB3644: The reference assemblies for framework ".NETFramework,Version=v3.5" were not found.

@ChrisMcKee

This comment has been minimized.

Copy link

ChrisMcKee commented Mar 16, 2017

@drewnoakes use msbuild

stevenvolckaert added a commit to stevenvolckaert/enterprise-library that referenced this issue Mar 18, 2017

Temporarily dropping support for .NETFramework 3.5. The current versi…
…on of the dotnet CLI tooling contains a bug causing the build of this target to fail, breaking CI builds. See Microsoft/msbuild#1333 for more information.
@JoshClose

This comment has been minimized.

Copy link

JoshClose commented Mar 24, 2017

I'm getting the error with .NET 2.0. I'm trying to do dotnet pack. Is there a workaround for packaging NuGet packages that will work?

@dasMulli

This comment has been minimized.

Copy link
Contributor

dasMulli commented Mar 24, 2017

@JoshClose you can directly call

msbuild /t:Pack /p:Configuration=Release

For version suffixes, add /p:VersionSuffix=beta-123 (however, note NuGet/Home#4337)

@JoshClose

This comment has been minimized.

Copy link

JoshClose commented Mar 24, 2017

How can I change the package output location? Sorry, I'm no too familiar with msbuild.

@dasMulli

This comment has been minimized.

Copy link
Contributor

dasMulli commented Mar 24, 2017

/p:PackageOutputPath=path\to\dir\

@NightOwl888

This comment has been minimized.

Copy link

NightOwl888 commented Apr 22, 2017

I got this working by adding the following to the .csproj file:

<PropertyGroup>
  <FrameworkPathOverride Condition="'$(TargetFramework)' == 'net35'">$(MSBuildProgramFiles32)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client</FrameworkPathOverride>
</PropertyGroup>

Unfortunately, the "normal" path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5 doesn't work in this case because it doesn't have a copy of mscorlib.dll.

@skarllot

This comment has been minimized.

Copy link

skarllot commented Oct 28, 2017

The @NightOwl888 solution stopped working again.

C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(165,5): error : Assets file '...\obj\project.assets.json' doesn't have a target for '.NETFramework,Version=v3.5,Profile=Client'. Ensure that restore has run and that you have included 'net35-client' in the TargetFrameworks for your project.

RouR added a commit to RouR/MicroDocum that referenced this issue Dec 19, 2017

mj1856 added a commit to mj1856/TimeZoneConverter that referenced this issue Feb 26, 2018

@Nirmal4G

This comment has been minimized.

Copy link

Nirmal4G commented Mar 8, 2018

@Thealexbarney There were some packages like Microsoft.TargetingPack.NETFramework.* for v4.5+ and Microsoft.TargetingPack.Portable.* from dotnet.myget.org months ago, but the team didn't announce anything.

I worked with it for a while, there were some issues, but it was better!

I (and many) would really like if those packs along with support for older versions were made public!

@nguerrera

This comment has been minimized.

Copy link
Member Author

nguerrera commented Mar 8, 2018

@RichardD2

This comment has been minimized.

Copy link

RichardD2 commented Apr 4, 2018

@NightOwl888's solution almost worked, except I have a strongly-typed resource file, and:

error : ResGen.exe not supported on .NET Core MSBuild

Looks like it's caused by #2272.

As others have said, using MSBuild is not an option; I need to build a multi-target NuGet package.

Looks like I'm going to have to drop the resource file and hard-code the strings. :(

@bruno-garcia

This comment has been minimized.

Copy link

bruno-garcia commented Apr 18, 2018

Should we we expect support from the CLI to .NET 3.5 eventually or is this just not planned?

@bradwilson

This comment has been minimized.

Copy link
Member

bradwilson commented Apr 18, 2018

I've been told it's not happening.

@jnm2

This comment has been minimized.

Copy link

jnm2 commented Apr 18, 2018

Immo edited #WontFix into my comment here, so... dotnet/designs#33 (comment)

@bruno-garcia

This comment has been minimized.

Copy link

bruno-garcia commented May 10, 2018

How do I get an SDK based project (multi)targeting net35 to build?

msbuild proj.csproj /p:TargetFrameworkVersion=v3.5 fails with:

C:\proj.csproj(1,1 ): error MSB4041: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.

Y-YoL added a commit to Y-YoL/UniCs2Cpp that referenced this issue Sep 2, 2018

Y-YoL added a commit to Y-YoL/UniCs2Cpp that referenced this issue Sep 2, 2018

@JohnHBrock

This comment has been minimized.

Copy link

JohnHBrock commented Sep 20, 2018

Yeah, that doesn't work for me, as there is no 3.5 version of System.Web available anywhere in that folder structure. 😞

@bradwilson Did you ever find a resolution for this? I'm in the same boat.

@bradwilson

This comment has been minimized.

Copy link
Member

bradwilson commented Sep 20, 2018

@JohnHBrock No. There is no solution.

@JohnHBrock

This comment has been minimized.

Copy link

JohnHBrock commented Sep 20, 2018

@bradwilson This seems to work OK, but I haven't had time to thoroughly test it:

  <ItemGroup>
    <Reference Condition=" '$(TargetFramework)' == 'net35' " Include="System.Web" HintPath="$(WINDIR)\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll"  />
  </ItemGroup>

This includes System.Web.dll as a dependency in the overall project by pulling it from the .NET 2.0 directory, and, combined with the @NightOwl888 workaround, seems to make dotnet build -f net35 succeed.

EDIT: A possible problem I've found with this approach: There are two versions of System.Web.dll under $(WINDIR)\Microsoft.NET\, one under Framework64\v2.0.50727\ (built for x64) and another under Framework\v2.0.50727\ (built for x86). In other words, System.Web.dll isn't built for Any CPU (aka MSIL). So if your project needs to target Any CPU, the lack of an Any CPU System.Web.dll poses a problem.

@skarllot

This comment has been minimized.

Copy link

skarllot commented Sep 22, 2018

@JohHBrock have you tried to copy files and directories from 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5*' to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v3.5'?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.