The official documentation does not work.
Do I need VS 2017 Preview?! Or to restart my pc every time I install "Latest stable 2.2.3" SDK's? Perhaps its not so stable? Should I try 2.2.1 lol
VS 2015 will work up for up to .NET Core 1.1 (now EOL). VS 2017 will work for up to .NET Core 2.2. .NET Core 3.0+ requires VS 2019.
It's not clear what your exact issue is, but the process is basically this:
Download the appropriate .NET Core SDK version. Be careful because the SDK version is somewhat independent of the .NET Core version. Pay attention to specifically what version of .NET Core the SDK supports, not the version number of the SDK itself.
Edit your project file and change the target to the new .NET Core version. This will be the minor version, not patch releates. In other words, for any .NET Core 2.2.X, you'd use netcoreapp2.2 as your target.
That's it. After you save, any NuGet dependencies of your project, such as Microsoft.AspNetCore.App will update to the latest version within that target, i.e. 2.2.X. However, note that some packages may not always have new versions. Most of the major parts of ASP.NET Core, for example, change enough with each version that the NuGet packages get bumped as well. However, it is possible that you may still use a 2.1.X package if nothing changed in that for 2.2. In any case, you'll be able to see in Visual Studio if it's fully updated or not.
Related
Just installed VS 2019 Pro on a new system. When I open a solution with .net 4.0 project, I get this error: Project Target Framework Not Installed.
When I choose download it, it goes here but does not have option for .net framework 4.0.
In project settings there is no option for .Net Framework 4.0 in targeting framework:
https://dotnet.microsoft.com/en-us/download/visual-studio-sdks?cid=getdotnetsdk
I have tried installing 4.6.2, 4.5.2, etc.
How can I get this project to open? It opens on my other machine. It has these options for Target framework in project settings:
Please don't say change the framework version, we need this older version for very old computers running XP and Win 7 that cannot be upgraded.
thank you
You have to go directly to their download site. As shown in another correct answer that was downvoted, it's still available even though it's past end-of-life.
https://stackoverflow.com/a/72870727/9008140
You can package the install files with your app just in case, although most likely your installer will see that it's missing and download it anyway.
You can try downloading .Net 4.0 here: https://dotnet.microsoft.com/en-us/download/dotnet-framework/net40
Mandatory warning: Installing an old, unmaintained .Net framework comes with security risks. It's up to you to determine how much those Windows XP PCs are vulnerable and manage said risks.
I have a .net core Blazor Server App which is currently using version 6.03 of .net core.
Version 6.04 came out a few days ago, and I need to upgrade the project and then publish it so it is using the new bits.
I have:
Install the latest SDK from here which includes 6.04.
I also used Nuget to ensure all libs are on 6.04.
However, when I open the project, and check the file versions, it is still using 6.03.
I have looked for any setting in the project file that would indicate which version of .net 6, it is using, but I don't see any such setting. I only see this setting:
<TargetFramework>net6.0</TargetFramework>
Is there some way to get VS to use 6.04 instead of 6.03?
After quite a bit of working with this, I found that the minor version is tied to the Version of Visual Studio that you are using.
So, I was using VS 2022 Version 17.2.0 Preview 4, and the .net 6.0.4 bits had not been released yet for this version. So those bits are not accessible from this version.
However, the 6.0.4 bits have been released for VS 2022 Version 17.1.5. So by downloading and installing 17.1.5, the project then opened up using 6.0.4 without any other changes.
I am sure that soon the bits will be released for the 17.2 version soon.
I am building an MVC Web API (Service) with Views returned in specific cases. As an architectural decision, I've been directed to NOT build the service project in .NET Framework 4.*. Rather, I am to attempt .NET 5.0 first, and then Core 3.1 if 5.0 doesn't work.
This service project in my solution will depend on a few class library projects, call them DataLibrary, ComplexLibrary, and DocLibrary. DataLibrary will depend on a Nuget package of Oracle, be it ODP or Oracle Managed Data, in order to query an Oracle database via an Oracle Package on that database. DocLibrary will depend on a Nuget package of Aspose Word & Aspose PDF. ComplexLibrary will depend on Oracle AND Aspose.
Here's my dilemma:
Aspose Word's latest stable release (21.6) will report that it is compatible with 5.0 and Standard 2.0, but not .NET Core.
Oracle Managed Data reports that it is compatible with Standard 2.1 or Standard 2.0, but not 5.0 or .NET Core.
My own libraries have reported that they are not compatible with my API .csproj if...
3a. The API is 5.0 and the libraries are .NET Core or .NET Standard
3b. The API is Core 3.1 and the libraries are .NET Standard.
Since my compile script naturally requires a run of Nuget to retrieve all the necessary dependencies, I cannot get a clean compile because I seemingly have no combination of versions for my WebAPI and libraries that satisfy each others' compatibility needs. Since Standard libraries are the only common .NET version that satisfy the needs of both Aspose & Oracle, What available version for my WebAPI (i.e. I don't believe that Standard is an option for anything other than a class library) is compatible with .NET Standard libraries?
Thanks.
Please see the following article https://learn.microsoft.com/en-us/dotnet/standard/net-standard.
.NET Standard is not a framework it is kind f specification and .NET Core, .NET 5, Mono framework etc are .NET Standard implementations.
So for library projects I would select .NET Standard and for the service .NET Core or .NET 5 (which is actually the next version of .NET Core)
Well, don't I feel silly.
Turns out, the issue wasn't incompatibilities within Aspose, Office, .NET Core, 5.0, and Standard, but a failure of a prior version of NuGet to handle the different versions.
While my VS 2019 install was able to compile the whole solution effectively, my local install of NuGet was not. This was due to VS2019 likely using the most up-to-date version as of this post (5.9.#), while my locally installed version was 4.9.#. Thus, VS was able to sail through while my compile script kept failing at the NuGet stage (which I have included prior to the actual compile.) Once I ran a NuGet update, everything was good to go.
Long story short: KEEP YOUR NUGET VERSION UP-TO-DATE!!!
I just recently installed preview 9. Looks like a Release Candidate will be available soon. This stuff is changing fast.
https://github.com/dotnet/core/blob/master/roadmap.md
Just going off memory, will one need to uninstall Preview 9 before installing the RC ?
The installers should automatically uninstall previous versions of the same release band, so the preview 9 installer (windows, judging from the visual-studio tag), should have uninstalled the preview 8 if present. A possible RC (if one is released before the final 3.0 version end of september) should also uninstall the preview.
But it is not necessary to uninstall it if you want to use the previews / RCs side-by-side. The side-by-side mechanism is the same as for different version of .NET Core and the .NET Core SDK. Not all projects need to use the same tooling / runtime (e.g. when you are migrating projects from preview8 to preview9 consecutively and thus want to work with both versions side-by-side).
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.