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.
Related
I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)
I just upgraded my TFS source to use DevExpress 15.2.5. However, now I get a bunch of warnings in the output such as
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3274: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
and
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3275: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it has an indirect dependency on the assembly "DevExpress.Data.v15.2, Version=15.2.5.0, Culture=neutral, PublicKeyToken=7ea533hgx2169hs3" which was built against the ".NETFramework,Version=v4.0,Profile=Client" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
along with about 30 other similar warnings.
It's obvious that something is out of sync with my assemblies because they are referencing the wrong versions. So I looked at my TFS project .csproj file. The version of DevExpress and .NET framework that are being referenced in there are correct.
I then went to the Microsoft.Common.targets file and opened in Notepad. I noticed that file is referencing the old version of everything. How do I get this in sync with my TFS assemblies?
It looks like you need to change your project to use the .NET framework version 4.5 on the project properties page:
Word of warning this may result in more warnings or errors depending on the .NET APIs you use.
I'm using Visual studio 2013 and I'm want to compile my project for linux (with MONO).
Is this possible to use VS2013 (with or without mono plugin) to compile my project to MONO file?
Yes, you'll be fine to use VS to build a .NET project that can run against Mono.
You'll be fine with the stock csc compiler and MSBuild (as both csc and the Mono compiler generate CIL all the same) just make sure that your project references Mono's assemblies rather than .NET's where there are breaking differences (e.g. System.Windows.Forms, etc). If you're doing ASP.NET or Console applications you should be fine without doing anything special.
As long as you use the versions of the DLLs that come from nuget instead of the references that are added by default by Visual Studio you should be fine, provided you recompile everything with xbuild.
At the moment there are some minor differences in the CIL that is outputted by msbuild and what the mono VM can run.
Just run xbuild in the root directory of your solution or project. It will detect the .sln/.proj file and build everything.
We're having the seemingly common error
Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
in a project that needs to be compiled against .Net 4.0 but is built on a build server running Windows Server 2012 (with .Net 4.5). The project is a web application that gets deployed to a web server running 2003, where installing .Net 4.5 isn't an option. There it runs against "classic" .Net 4.0
From similar questions, we're trying command-line options to MSBuild:
/property:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
We also tried various combinations of
/property:ReferencePath="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
/property:NoStdLib=true
/property:NoCompilerStandardLib=true
The reference assemblies (including the .dll files) are in fact installed in that place on the build server. But when we deploy the website and visit the home page, we get that error. (Interestingly, on a page reload, the error disappears, and the site operates normally.) What are the MSBuild parameters necessary to compile against the .Net 4.0 assemblies?
Update
I turned on ludicrous-level logging on MSBuild, and I see that apparently it is building against the .Net 4.0 reference assemblies:
Resolved file path is "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
and I didn't see any mention of assemblies outside that folder or the build server's working directory. So it appears to compile properly, but when deployed on the web server, it throws the exception.
As to the exception going away on a page reload, I wonder if that's related to the markup pre-compile step. We're running aspnet_compile on the build server. Maybe if there's an exception coming from a generated assembly, the web server will re-compile it. And the recompiled assembly is fine, because it was created with true .Net 4.0.
Well the answer turned out to be borderline embarrassing. After we confirmed from detailed MSBuild output that it was in fact building the website project against the right reference assemblies, we realized that there are several in-house NuGet packages in the project that had been built against .Net 4.5. One of them was chock full of extension methods, which is what causes the exception. Rebuilding them against .Net 4.0 fixed the problem.
Which brings up an interesting issue. If a 3rd-party NuGet package is compiled for 4.0 but using 4.5 references, we'd be in the same situation, but not able to fix it. So the lesson for package publishers is to ensure your 4.0 version is compiled against the reference assemblies.
Can anyone tell me why when I create Monotouch projects in the latest drop of MonoDevelop it is targeting the 1.0 framework instead of 3.5, as my projects in earlier versions do? This causes it to not be loadable in VS2010, which I tend to use for coding, while building/testing in MonoDevelop. Here is the version info:
Release ID: 20509002
Git revision: 35a0397615c02f7830d46dfcd31a6c0cb86e9f85
Build date: 2011-04-06 03:37:58+0000
And here is the difference in the csproj files between versions:
Old:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
New:
<TargetFrameworkVersion>v1.0</TargetFrameworkVersion>
The v3.5 was a bug; MonoTouch projects never targeted the .NET v3.5 framework. They target the MonoTouch framework, which is arbitrarily versioned as v1.0.
Improvements in MD 2.6 have allowed us to deal with custom .NET frameworks in a similar way to VS 2010. This means that instead of storing the "closest" .NET framework then internally switching it to the correct framework after the project is loaded, we can directly handle particular project types using a particular custom framework.
If you want to load MT project in VS, you already have to make changes to the project - temporarily remove the project flavor GUID (though a trivial VS addin could make that unnecessary). This framework version fix means that you also have to change the target framework to one that VS has. For MonoTouch 4, rather than using .NET 3.5, I would recommend using either Silverlight 4 or .NET 4.
The best solution would be to set VS to actually use the MonoTouch framework, so you'd get accurate code completion and compilation. In VS 2010 that's now possible. Simply set the TargetFrameworkIdentifier of the project to "MonoTouch", then install the custom framework by copying all the MonoTouch framework assemblies to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoTouch\v1.0 and adding a FrameworkList.xml manifest in the RedistList subdirectory.
I've created a small open source project that enables you to build MonoTouch projects inside Visual Studio 2010. The readme for the project also explains how to get round the "v1.0" problem for the target framework version.
The project is available at https://github.com/follesoe/VSMonoTouch.
Since that's a Monotouch project, nobody expects it to work for Visual Studio or Windows.