I have a solution that is being referenced by a MSBuild project. In the solution, I am referencing several projects that are targeting .NET 4.0. How can I tell MSBuild to ignore the project's configuration and just target .NET 3.5?
A command similar to the following should work
msbuild YourSolution.sln /tv:3.5 /p:TargetFrameworkVersion=v3.5
or
msbuild YourSolution.sln /p:TargetFrameworkVersion=v3.5
/tv (or /toolsversion) Indicates which version of the MSBuild tools you want to use, and the property TargetFrameworkVersion indicates the target framework. In your case just specifying that property should be fine, but if you want to use the 3.5 MSBuild toolset you can sepcify it with /tv as I did in the first command.
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'm building a .NET Standard component using VSTS-Build and GitVersion. And because its .NET Standard I'm having to use msbuild /t:pack instead of the nuget pack step.
This has resulted in the package version number always being 1.0.0 which I assume means that "PackageVersion" isn't being set. The GitVersion documentation says:
the following MSBuild properties are set when UpdateVersionProperties is true
but there doesn't appear to be an option for that.
Anyone know how to get this to work?
Project file:
I changed 2 things from a working build definition, I disabled the Nuget Pack step and I added "/t:pack" as an msbuild argument in the Visual Studio Build step.
Nuspec file.
You should set the GitVersion task ahead of MSBuild task. And it will generate nuget package version with 1.1.0. But it won't update the new version (1.1.0) in your source code, so when you build once again, you will always get the nuget package version 1.1.0.
And there has another way to generate nuget packages and specify package version as you need. Detail build definition as below:
.NET Core task with command restore: specify the path to .csproj.
.NET Core task with command build: specify the path to .csproj.
.NET Core task with command pack: specify the path to .csproj and the package version (/p:PackageVersion) as you need.
To use Gitversion variables for nuget package, you just need to add the argument /p:PackageVersion=$(GitVersion.Major).$(GitVersion.Minor).$(GitVersion.Patch) in .NET Core pack task.
The variables $(GitVersion.Major), $(GitVersion.Minor) and $(GitVersion.Patch) are auto generated after executing GitVersion task.
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.
We are using Mage.exe to generate our application's manifests as part of our build process. Upon upgrading to .NET 4 we now find it generates an invalid manifest.
The reason is there isn't a compatibleFrameworks attribute being set in the application manifest which we generate every build.
Is there a way we can make Mage.exe add this element or should we only ever update existing manifests?
There is a separate copy of mage.exe built for .NET 4.0. Try using this copy from C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools (or ...\v7.1\Bin\NETFX 4.0 Tools depending on which SDK version you have installed).
I was actually having this same problem and using the mage.exe from NETFX 4.0 Tools fixed it for me.
Add this to your GenerateDeploymentManifest MSBuild task
TargetFrameworkMoniker=".NETFramework,Version=v4.0"
and that should fix it
Is it possible to build Visual Studio solutions without having to fire up MonoDevelop?
Current status (Mono 2.10, 2011): xbuild is now able to build all versions of Visual Studio / MSBuild projects, including .sln files. Simply run xbuild just as you would execute msbuild on Microsoft .Net Framework. You don't need Monodevelop installed, xbuild comes with the standard Mono installation.
If your build uses custom tasks, they should still work if they don't depend on Windows executables (such as rmdir or xcopy).
When you are editing project files, use standard Windows path syntax - they will be converted by xbuild, if necessary. One important caveat to this rule is case sensitivity - don't mix different casings of the same file name. If you have a project that does this, you can enable compatibility mode by invoking MONO_IOMAP=case xbuild foo.sln (or try MONO_IOMAP=all). Mono has a page describing more advanced MSBuild project porting techniques.
Mono 2.0 answer (2008): xbuild is not yet complete (it works quite well with VS2005 .csproj files, has problems with VS2008 .csproj and does not handle .sln). Mono 2.1 plans to merge the code base of mdtool (MonoDevelop command line build engine) into it, but currently mdtool is a better choice. mdtool build -f:project.sln or man mdtool if you have MonoDevelop installed.
for now as per August 2017 we can use
msbuild
command as xbuild is depreciated.
xbuild now supports solutions and projects, both VS2005 and VS2008.
I think you are looking for xbuild:
http://www.mono-project.com/Microsoft.Build