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 ...
Related
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'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
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.
When I try to run the dll I compiled in Visual Studio 2010, I get the following message: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. I'm guessing this means that I am a too recent version of Visual Studio. Is there a way I can build the dll as an earlier version?
All assemblies in your final solution, be they dlls or exes, in different solutions or in the same one, must target the same version of the CLR. You can ensure they do by configuring targeting in your 2010 solution.
Most likely you're targeting 4.0 in your dll's project. Crank it back to 3.5 or earlier and see if that fixes the problem.