I have project that have to be build with different framework versions including .net 1.1.
To build project with .net 1.1 I need to change Project's ToolsVersion to 2.0, but for other frameworks it must be set to 4.0
Is it possible to implement such behavior in Visual Studio?
Something like this in csproj file:
<Project ToolsVersion=" if $(Configuration) == DOT_NET1_1 THEN '2.0' ELSE '4.0'">
No. The ToolsVersion attribute is set automatically by the version of Visual Studio used to open the project file. The properties that the ToolsVersion controls are reserved and cannot be modified by msbuild. I don't have experience with compiling in .NET 1.1, so I don't know if this is the most elegant solution, but:
In lieu of constantly changing this attribute, the only thing I can think of is to create two different project files, one for compiling in .NET 1.1 and the other for compiling in the other frameworks. They can both reference the same source files, referenced dlls, etc, just be sure not to have them in the same solution, or Visual Studio 2010 will try to upgrade the project file with the older ToolsVersion.
Related
I have a C# class library project which I consume from a C++ project. This works perfectly well when:
the C# project has TargetFramework set to netstandard2.0
the C++ project has TargetFrameworkVersion set to v4.7.2
However, I now need to upgrade the C# library to net5.0...
the C# project has TargetFramework set to net5.0 (using new style project file)
the C++ project has TargetFrameworkVersion set to v5.0
and receive this error....
C:\Program Files\Microsoft Visual
Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1806,5):
error : Project '..\cslib\cslib.csproj' targets 'net5.0'.
It cannot
be referenced by a project that targets '.NETFramework,Version=v5.0'.
Note that it's not possible to set the TargetFrameworkVersion for the C++ project to "net5.0" or "net5.0-windows" since that results in a project load error:
It's not clear that "v5.0" is the correct TFM for a C++/vcxproj format file - it's possible msbuild is just falling back to v4.7.2 by default but I can't think of a better alternative.
Is there a way to accomplish this? It seems like it should be possible to target net5.0 in a C++ project by now. (I'm using Visual Studio 2022 Preview and PlatformToolset is set to v143 which is the latest).
It's a bit tricky, but the following should help:
If using the GUI, the following settings need to be made in properties: Under "Root->Extended" setting "Common language runtime support": "Net Core runtime support /clr:core" and ".NET Core Target framework": ".NET 5.0" (you might need to click "apply" after choosing the first, to get the possible settings in the second box to update)
In the .vxcproj, this results in:
...
<PropertyGroup Label="Globals">
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
<Keyword>ManagedCProj</Keyword>
<TargetFramework>net5.0</TargetFramework>
...
</PropertyGroup>
and (once for each build configuration):
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<CharacterSet>Unicode</CharacterSet>
<PlatformToolset>v142</PlatformToolset>
<CLRSupport>NetCore</CLRSupport>
...
</PropertyGroup>
Note that it is not possible to create C++ exes in .NET Core. C++/CLI projects must be libraries and cannot contain the main entry point (create a stub-loader C# project if you have to).
You may then experience:
error NETSDK1145: The Apphost pack is not installed
This documentation suggests this can be overcome by modifying the project file but if that does not work, a global.json file can be added in the solution root folder to point to the desired SDK.
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I am having a rough time figuring out how to setup cross-targeting inside a Visual Studio 2017 project and I have not been able to find any examples.
I started out with a .NET Standard 1.5 project and to keep it simple I am just trying to add .NET Standard 1.6. If I understand the documentation correctly, I should now be able to do all of this inside the csproj file without having to mess with a project.json or nuspec file.
I've tried all of these values but none seem to work:
<TargetFrameworks>netstandard15;netstandard16</TargetFrameworks>
<TargetFrameworks>netstandard1.5;netstandard1.6</TargetFrameworks>
<TargetFrameworks>.NETStandard,Version=v1.5;.NETStandard,Version=v1.6</TargetFrameworks>
This is the only source of documentation I can find on the feature and it doesn't contain a full example:
https://docs.nuget.org/ndocs/schema/msbuild-targets
https://docs.nuget.org/ndocs/create-packages/supporting-multiple-target-frameworks
I've gotten this to work on latest Visual Studio 2017. As described in this post https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ it is the correct way to do it. My csproj file looks like this:
<PropertyGroup>
<TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
</PropertyGroup>
Visual Studio 2017 RC release notes also has this listed as a feature (under .NET Core and Docker):
Cross-target multiple target frameworks in one project.
My mistake at the start was that when I first created the project the property was called TargetFramework, I tried to add multiple targets and VS did not like that at all. It just crashes then... So make sure to rename it to TargetFrameworks and it should work.
Is there a way to transfer a Visual Studio project to the MonoDevelop environment?
at FAQ - MonoDevelop it is said that:
MonoDevelop can open, manipulate and save MSBuild-based projects directly in mopst cases. In fact, since MonoDevelop 2.0 the default project format has been VS2008-style MSBuild projects, but VS2005 and VS1010 formats are also handled.
But when I try to open my (ASP.NET Web Application) .vbproj in MonoDevelop, I get:
Load operation failed. Project does not support framework
'.NETFramework,Version=v4.0'.
Should I alter project settings, allowing different .NETFramework version or do I have to use some 3rd party softwares to translate my projects config files?
EDIT:(Resolved)
If your project is not that big yet, create a new project in your Microsoft Visual Studio(MVS) with .NET Framework 3.5 and then it will be possible to open it with MonoDevelop, else edit your projects Debug/Release config files and delete everything that has "4.0" information about this project, plus .vbproj file in are previous doesn't work and do the same, search for 4.0 information. (Applicable for framework 4.0)
OR
Change your project settings as it is described here:
http://msdn.microsoft.com/en-us/library/bb398202.aspx
What version of MonoDevelop are you using? MonoDevelop 2.8 can open .NET 4.0 projects (I believe 2.6 can as well). In fact, in 2.8 .NET 4.0 is the default for all new projects.
MonoDevelop's VB.NET addin still doesn't support .NET 4.0. It would work for C# projects.
Using a text editor, change your *.vbproj file to add the following line:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
to the first PropertyGroup, e.g.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
</PropertyGroup>
.net framework 4.0 not yet completly implemented in mono
but includes most of the features
try to download latest version of mono and retry:)
I had the same problem in version 3.0 of MonoDevelop.
VBNET development have changed the runtime. NET
Tools> Options> Runtimes. NET
I have marked as default MONO 2.x
I have a Visual Studio 2010 Solution with a class library project. What I want to do is compile 2 DLLs on build. I want to compile against .NET 3.5 and .NET 4.0 respectively. Something like below.
myproject\bin\debug\3.5\assembly.dll
myproject\bin\debug\4.0\assembly.dll
Is this possible?
Maybe you'can write a simple problem to execute on each build, it simply does:
make a copy of your working project file (*.csproj, *.vbproj, etc.)
edit the target info from 4.0 to 3.5 (or from 3.5 to 4.0) and update other related properties, it should be simple enough.
call msbuild.
I've used this approach before for different purpose.
The target framework is part of the application project settings that cannot depend on the configuration (unlike build settings).
I'm afraid you will have to create a separate project for each framework version.