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.
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 intend to build simple Winform application just to allow user to automate their file creation and store the last filled form in a file to keep it for next run.
thus, I'm not interested in creating installer for this simple Winform application. I expected to only compile it to .exe and let it run on other computers.
I develop the application using VS2019 community with target .net 4.6.1
It won't run on computer with Windows 10 with only .net framework 4.8
We are not able to install framework 4.6.1 since it says an earlier version of .net framework is already installed.
Should I recompile my application with target .net framework 4.8?
Can't I compile my application to run on any computer which at least has 4.6.1 or newer? without installer.
(I don't really understand the .net framework backward compatibility truly mean)
my application uses:
library of user32.dll for SetForegroundWindow function
to create .ini file
Finally it works. Even compiled to target .NET 4.6.1 still work on .NET 4.8 computer actually.
The issue is because my application is targeting to another application using interope COM interface, while the license is not sufficient for the user to allow COM interface.
we notice it when we finally create a pure simple windows form, then step-by-step compiling while adding each feature.
Sorry Every Body for this silly case. And my special apologize to evry1falls for spending your time.
I'm thinking to change this Question or delete it. because it is not the issue at all
The Actual Issue is:
I created Windows Form Application starting from a blank Project. And I don't know that the .NET Unhandled Exception is not activated by default.
When created from Windows Form Project Template, the Unhandled Exception message shown.
I created another Question about it: Here
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.
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
I'm working on a project started in VB9 (VS 2008) and now I've migrated to VS2010 (VB10) but on the production server the IDE is still VS 2008. On my developement enviroment the code compiles fine, but sometimes, - let's say - I forget an _ at the end of the line which causes the VB9 compiler to throw an error.
So the question is, how could I build a project with the VS 2010 IDE but VB9 compiler? Or to force the VB10 compiler into VB9 mode?
Unfortunately no there is not a way to accomplish this. When compiling in Visual Studio you aren't actually using the command line compiler. Instead you use the inproc hosted compiler (true for both VB.Net and C#). This compiler, while capable of outputting completely valid IL for down targeted platforms, is the version tied to Visual Studio (in this case 10.0).
There is no general way to shell out to a different version of the compiler or to the command line and get the behavior you're looking for.
What you can do though is set the language version of the compiler to be 9. This will issue warnings for a subset of parse level constructs which are not supported in VB9. This cannot be done from the IDE but can by editing the project file directly and inserting the following
<PropertyGroup>
<LangVersion>9</LangVersion>
</PropertyGroup>
Original Answer: Valid for targeting 3.5 but not this question
What you want to do is have your VB project target the 3.5 framework. This will cause the compiler to issue warnings on items that are not valid like _'s.
This can be done from the project properties page.
Right Click on the project and select properties
Go to the compile tab
Set the target to 3.5