I have a C# .proj file that using .Net Framework 3.5. Currently the solution that ties the .proj files uses Visual Studio 2008. Our daily build currently uses MSBuild 3.5. I know that you can specify the TargetFramework in MSBbuild 4.
My question is: do I have to convert my project file using Visual Studio 2010? I am assuming the conversion only affects the .sln file.
Conversion using Visual Studio 2010 is the easiest way, but you can just update your project files manually: just add ToolsVersion="4.0" attribute on the Project node. So yes, you have to convert your .proj files too, changing only the .sln is not enough.
Related
I have converted a VS 2019 using .NET 4.8 csproj file to VS 2022 using .NET 5.0
Everything builds however my post processing command fails.
It uses $(TargetPath) which seems to be no longer available.
What do we use instead?
Found the answer here PostEvents
in other words take a copy of your PostBuild event script, edit your project file and delete the PostBuild event section. The open the project file in Visual Studio and recreate the PostBuild event. This will create it using Targets
I work in Visual Studio. It seems for me, that, if I change anything in imported .targets file, the new version of .targets is not reimported to main project while building it. If I reopen my project (I.e. close and open again Visual Studio) and then launch build - the new version of .targets works.
Is it possible to tell Visual Studio to import .targets at any rebuild?
I tried use "rebuild" and "clean" solution and project, without any result regarding the problem.
Re-evaluating imported files is done by the new CPS-based project systems that are used for .NET Core / .NET Standard projects.
For VS versions before VS 2019, you may also need to indicate to MSBuild that the imported targets file should also re-trigger incremental build by adding its path to $(MSBuildAllProjects) (this is no longer needed in MSBuild 16 / VS 2019):
<PropertyGroup>
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
</PropertyGroup>
But for "classic" .NET Framework / ASP.NET projects, you still need to close and re-open the solution for changes to take effect inside the IDE.
Also see this GitHub tracking issue for the legacy project system.
I have build this project as .Net standard project and i am facing this error issue in jenkins when I build this project:
C:\Users\tahab.jenkins\workspace\Mondaytest\Calculator\Calculator.csproj(1,1):
error MSB4041: The default XML namespace of the pr.oject 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
element. If the project has been authored in the old 1.0 or
1.2 format, please convert it to MSBuild 2003 format
Make sure you use recent versions of the MSBuild task you use to build your project.
You need too use the Visual Studio 2017 (Build Tools, Full, ..) version of MSBuild - which is local to the Visual Studio installation - to build your project.
You may need to confiure the path to MSBuild, which would be - depending on the version installed on the build gent - similar to
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe
This error happens if you try to build new projects with older versions of Visual Studio / MSBuild or even with the old version of MSBuild that is part of .NET Framework.
I am trying to compile my Visual Basic .NET project named Myproject.sln via command line commands. I need to build and compile that solution.
My Visual Basic .NET compiler is called vbc.exe. Any idea how I do that thing?
I am using Visual Studio 2005 , and I have already read Microsoft's tutorial, "Building from the Command Line (Visual Basic)".
The .NET framework (version 2 and above) comes with a command line build utility called MSBuild.
You can use this to build your Visual Studio project/solution files.
From the command line:
msbuild Myproject.sln
Just run MSBuild and specify the .sln file as a command line option:
msbuild myproject.sln /p:buildmode=release
You could look at using MSBuild. That's probably the best approach.
Your .sln file is a valid MSBUild project file, so if you open the Visual Studio command prompt from the start menu and browse to your project location,
c:\...\msbuild MyFile.sln
... for example, it should just work.
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.