I'm attempting to create a 3.5 build from a 4.0 set of code. It almost works the following msbuild options: /tv:3.5 /p:targetframeworkversion=v3.5. The issue is that I get a conflict for those classes that have moved to new assemblies in 4.0, for example:
error CS0433: The type 'System.Web.Security.RoleProvider' exists in both 'c:\Windows\Microsoft.NET\assembly\
GAC_MSIL\System.Web.ApplicationServices\v4.0_4.0.0.0__31bf3856ad364e35\System.W
eb.ApplicationServices.dll' and 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\
System.Web.dll'
How do I tell msbuild to pickup the System.Web assembly? Can I tell it to ignore the 4.0 directory?
sounds like a similar issue to what we had, ended up with Hf from Microsoft
TFS2008 to TFS2010 migration upgrade
Related
I'm getting the runtime error:
InvalidOperationException: Can not find assembly file mscorlib.dll at '...\bin\Debug\net462\refs,...\bin\Debug\net462\'
This had not been a problem until I updated to version 15.3.1 this morning, and installed the .Net Core 2.0 SDK.
The DLL's are present in my ~\.nuget\packages folder. I'd had the same issue with the "Microsoft.Csharp.dll" assembly until I copied and pasted it into the stated folder.
I tried specifying to use .Net Core 1.1.0 via a global.json file, but then I get the build error:
The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK.
This error goes away if I clean the solution then restore Nuget packages via Command Line- not via the GUI. However it comes back if I change the version of a nuget package.
OK, this seem slightly different to my issue here: Visual Studio update 2017 15.3.1 forces ASP.NET Core SDK 2.0, which then doesn't find "reference assemblies"
If you install the SDK 2.0 from https://www.microsoft.com/net/download/core
You will then "probably" be able to build and run the project again but you'll be back to having the missing Microsoft.CSharp.dll / mscorelib.dll error.
If you then make sure the dependency is correct for the netstandard version:
<DependsOnNETStandard>netstandard1.5</DependsOnNETStandard>
See here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard for the right version for you. My project is using core 1.1 targeting the full framework 4.6.1 and targeting netstandard1.6 has worked for me.
The final piece of the puzzel, was found on the GitHub issues here: https://github.com/dotnet/sdk/issues/1488
Add the following to your references in the .csproj file:
<PackageReference Include="Microsoft.Extensions.DependencyModel" Version="2.0.0" />
This will then build the project as a 1.1 project, but using the 2.0 SDK (which from what I can tell, it's supposed to do!). I can now run the project, update packages and generally got on with my work!
I was setting up number of projects to build NuGet packages and push onto NuGet server, so it could be later used by Octopus Deploy.
All was fine until I needed to apply the same process to legacy projects. The error was:
error MSB4062: The "OctoPack.Tasks.CreateOctoPackPackage" task could not be loaded from the assembly ...\OctoPack.Tasks.dll. Could not load file or assembly 'file:///...\OctoPack.Tasks.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. Confirm that the declaration is correct, and that the assembly and all its dependencies are available.
Now I understand that OctoPack was not built for .Net 2.0, but just wonder if anyone hit/solved that problem.
Are you able to change the build target of the application from 2.0 to something more recent? If so, I would upgrade my app, rather than look for a downgraded version of Octopack.
Alternatively, you can use NuGet.exe to create packages rather than using OctoPack. I actually prefer OctoPack, but NuGet.exe wouldn't care about your .NET version.
I ended up amending the Octopack code to work with .Net 2.0 and MSBuild 2, which is successfully applied to all our .Net 2.0 and 3.5 applications being packaged on the CruiseControl server.
If someone is in a similar situation here is the amended code (forked from the original Octopack)
I got a some projects that need to be built for both .Net 3.5 and .Net 4 in VS2010.
The projects got different configurations and I edited the project file to include
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
or
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
under each configuration.
This has worked fine in C# projects for a long time but now I need to do the same for a VB.Net project.
The strange thing is in VB.Net where the resulting v3.5 assembly got references to both mscorlib 2.0 and mscorlib 4.0
My guess is the mscorlib 4.0 reference comes from the Microsoft.VisualBasic reference.
So my question is how I can get VS2010 to load the .Net 3.5 version of Microsoft.VisualBasic (8.0.0.0) in one project configuration and the .Net 4 version (10.0.0.0) in another?
Some background on why I need to do this: The project work as plugins in another application. The application can run in CLR4 or CLR2 (older versions) but the plugin need to work with both. If I target .Net 3.5 it will load fine in both CLR2 and CLR4 but the debugger in VS2010 will not work in CLR4. i.e. I need to target .Net 4 for the debug version and .Net 3.5 for the release version.
We're using Cruse Control to manage our build process.
AS we convert vs2008 projects to vs2010, we're leaving the target framework set at 3.5 for web and class library projects.
At this point we're not going through and converting all our solutions to vs2010; not if we don't have to.
I recently updated the MSbuild project files that cruise control uses to point at MSBuild 4.0 so our build process would be able to build vs2010 projects.
C:\windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
All was well until a web project that was targeting the 4.0 framework was committed.
At which point this error popped up:
CS0433: The type 'System.Web.Routing.RouteCollection' exists in both c:\Windows\Microsoft.NET\assembly\GAC_32\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll and c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Web.Routing.dll in Global.asax.cs(15, 43)
At which point I became aware of the Windows/Microsoft.NET/Assembly folders.
Now... All the MSBuild projects, even though they were using MSBuild 4.0, still had the tools version set at 3.5.
So why was a 3.5 targeted build looking at the new 4.0 assembly folders and finding this conflict? Probably because I was using MSBuild 4.0. But if I can change the toolVersion that MSBuild uses, you'd think I can tell it to target 3.5 without worrying about these potential conflicts.
To resolve this issue, I went to the relevant MSBuild project files that cruise control uses and changed their toolsVersion to 4.0. This got passed that conflict error. But now everytime it tries to build a project that's in a solution that we haven't yet converted to a vs2010 project, it breaks with an error like this:
MyProject.csproj in SomeFilePath:
LC0000: 'Could not load file or assembly or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.' in LC(0, 0)
If I open the solution that contains that project in Visual Studio 2010 and do the conversion, build it and commit that and force another build, I get passed that error only to find that another not yet converted project is tossing that same error.
So now I am for sure using MSBuild 4.0 and for real targeting the 4.0 framework. Why can't 4.0 build 3.5 projects or vs2008 solution projects?
The issue is that you have migrated part of your projects to to visual studio 2010. Any 2008 project that references a 2010 project (by project reference) will give you this compile time error. Try updating all .csproj files to 2010 and try rebuilding again.
I've thrown together some code to tinker with the new .Net 4.0/VS 2010 pieces, but I can't seem to find a build of my logging framework of choice (log4net) for 4.0, and I'm getting reference errors with the 2.0 version. Is there a 4.0 version available somewhere? I'm not asking for new features, just a version that's already been rebuilt against the new assemblies. Anyone know where I can find a build of 1.2.10 built for the 4.0 framework?
log4net has a known issue of referencing a System.Web component which is not part of the .NET Framework 4 Client Profile and the VS2010 by default sets project target to be the lightweighted Client Profile.
The solution is to change the target to .NET Framework 4:
Right click project -> properties -> Application.
Change:
.NET Framework 4 Client Profile
to be:
.NET Framework 4
... and that should work, i.e. you can use log4net again...