I have no problem building my VB project in both VS 2010 and 2012 againt .NET 2.0.
However, the MSBuild refuses to build it because it does not like one VB language feature introduced in VS 2010 (it is "implicit line continuation" to be more specific).
I tried the following parameters for MSBuild (from .NET 3.5):
/p:TargetFrameworkVersion=2.0
/toolsversion:3.5
This does not build as the VB feature I use have been introduced in 4.0 tools.
So I changed toolsversion to 4.0 (and using MSBuild from .NET 4.0):
/p:TargetFrameworkVersion=2.0
/toolsversion:4.0
And now MSBuild complains about another thing:
C:\Users\Libor\AppData\Local\Temp\.NETFramework,Version=2.0.AssemblyAttributes.vb(6,24):
error BC30002: Type 'System.Runtime.Versioning.TargetFrameworkAttribute' is not defined.
[project.vbproj]
The only solution now for me is to open my project in VS 2008 and manually correct the code so it is compatible with all tools. But I hope MSBuild can be configured so it builds properly, as VS can build the project against .NET 2.0, too.
Similar question and answer here. They key is going to be:
msbuild YourSolution.sln /tv:4.0 /p:TargetFrameworkVersion=v2.0
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 have to continue a program witch have been coded with Visual Studio and the framework .NET framework 4 but the thing is : I have a macbook.
After many researches I have found that by using Mono it was possible to code in vb.net with a mac. However, the project is working on Windows computer but I get this warning:
"warning MSB3256: No assemblies were read in from the redist lists. A TargetFramework profile exclusion list could not be generated."
and this error:
"error MSB6006: "vbnc.exe" exited with code 1"
So I'm guessing that he doesn't recognize that mono should replace .NET framework. I am executing the code with MSbuild, maybe that is the issue?
Unfortunately you are stuck.
Microsoft would like to bring C#/VB and .NET Core to Mac via Visual Studio for Mac, so you should not attempt to bring any .NET Framework projects to Mac via Mono any more.
This warning is more critical to VB developers, as Mono's VB support (vbnc.exe is Mono VB compiler) is experimental and does not support all VB latest features.
However, for .NET Core development, VB is also not yet ready to be used, and should be available in a few months when Microsoft ships .NET Core 2.0.
You can definitely play with VB by using .NET Core 2.0 Preview build,
https://www.infoq.com/news/2017/05/netcore2preview
But then you cannot use VS for Mac, and have to use an editor such as Visual Studio Code.
For some reason, Mono uses vbnc by default although there is a Roslyn-based VB compiler built-in to Mono, vbc. Interestingly, vbnc is even not being installed with mono-devel package and it still being used by default.
If you installed vbnc and started to get this message:
"error MSB6006: "vbnc.exe" exited with code 1"
you need to instruct Mono to use vbc instead and your code will build. The most reliable way to do it is to set it per project, by adding the following XML to your vbproj file:
<PropertyGroup>
<VbcToolExe>vbc</VbcToolExe>
</PropertyGroup>
The code should be placed inside the root <Project> tag.
I have recently installed VS2015. Yay! \o/
However, one of my C++/CLI projects showed this message when upgrading from VS2013:
The following project(s) uses an earlier version of the Visual C++ compiler and libraries. The project(s) will be upgraded to use the Microsoft Visual Studio 2015 compiler and libraries. Any managed or native code project(s) using C++/CLI extensions will be automatically upgraded to target .NET Framework 4.5.2. Note: If you do not upgrade the project(s), building your project(s) will require the corresponding version of Visual Studio to be installed.
I ok'd the warning, but now code which compiled previously in VS2013 no longer compiles, for instance:
void WritePixels(array<unsigned int> ^ rgbaData);
has the error
'std::array': too few template arguments
'^': cannot use this indirection on type 'std::array'
Also the project properties do not allow me to switch target .NET framework version (it is grayed out).
Is it possible for C++/CLI projects to target .NET 4.0 using Visual Studio 2015? Are there any syntax changes in C++/CLI since Visual Studio 2013 that I need to know about?
Just an update for posterities sake.
I solved this by workaround, by not using C++/CLI at all, but using the amazing, adaptable SWIG Platform Invoke Generator library.
No C++/CLI = no issues with .NET Framework versions, no issues with x64/86 bit and .NET Any CPU.
Problem Solved ...
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 were using nant for building our project (10+Class Lib) and a Web Site which was based on the ASP.NET 2.0. Recently we are in the process of moving towards the ASP.NET 3.5. I searched in the net and found that nant doesn't support 3.5.
I am also looking in to option of migrating MSBuild.
Is the MS Build right candidate for this?
I heard people saying that MSBuild is slow? is it True?
With MS Build can I have a Single step build ? in nant all I will do is to call nant.ext and give a build file it will do a build and give me the output.
NAnt can easily be made to support .NET 3.5 - we use it here. Rather than claim credit, check this blog post.
Have a look at the Nant Site
.net Framework 3.5 is supported
In MsBuild you can have a single step build. Nant can be used with .Net 3.5 but is always behind the times (.Net 4.0 is soon to be shipped). Nant .86 beta1 has issues with x64 Windows Server 2003 (You will need to use a nightly build). I have used both and prefer MsBuild. For more details check out an older blog post I wrote Nant vs MsBuild