The packages at https://www.myget.org/gallery/aspnetrelease target aspnet50, and when I try to install them I get:
You are trying to install this package into a project that targets
'.NETFramework,Version=v4.5', but the package does not contain any
assembly references or content files that are compatible with that
framework.
Is there a way?
You can't do that (currently). If you insist on working with ASP.NET vNext in VS2013, you can use it as an editor and run everything from the commandline with the tools from the aspnet Home repository.
You should install the newest CTP of VS14 if you want to work with asp.net vNext, which you can download the newest version of from here and learn how to use it in this guide. ASP.NET vNext is in alpha currently, so documentation and information can be a bit sparse. aspnet50 is the (current) name for the new .Net framework introduced with ASP.NET vNext.
I was able to manually download the nuget packages and had no problem referencing from VS 2013.
Related
I am working in Visual Studio 2019, and .net Core 2.1.1.
I am currently working on trying to get Identity Server 4's WsFederation integrated. In the latest instructions I could find, he mentions adding System.IdentityModel to the app through the project.json. Project.json seems to be deprecated now in .net core projects, and I am having a hell of a time figuring out how to add a freaking .net assembly to my project. Do I really need to just copy the file into the project and reference, cause that just seems wrong.
Instructions I am using:
https://www.scottbrady91.com/Identity-Server/IdentityServer-4-SharePoint-Integration-using-WS-Federation
Seems to all come back to the project type. I had created the project with AspnetCore and so I couldn't reference any .net framework assemblies, because you can't go back once you have made that choice. However, if you create the project specifically under the .net framework, you can move forward into the core frameworks, and hosting libraries of core. Which then allowed me to pull in the System.IdentityModel assemblies I needed to continue forward.
I'm trying to set up a build configuration for an ASP.NET Core (built on .NET full framework 4.6.2) project.
I'm Using TeamCity Enterprise 2017.2.3 (build 51047)
The .NET Core SDK is installed on the build server, along with 4.6.2 of the .NET Framework.
I am getting the following Build Error Message:
... This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\NETStandard.Library.2.0.3\build\netstandard2.0\NETStandard.Library.targets.
Anyone come across this error before?
I added the latest recommended Nuget exe (4.6.2) as well.
The build step upon which it is failing is a .NET CLI (dotnet) step.
I've set the Command to build
and the Projects to the Solution file.
Dotnet CLI is definitely installed and is version 2.1.300
Yeah update the build tools on the TeamCity server, you're probably using the latest Visual Studio version on your local machine but your build tools on the build server are slightly out of date, probably earlier than v15.5.
https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15
Also ensure that you have selected to add the .NET Core 2(+) build tools as they include the .NETStandard and aren't selected by default. See https://github.com/dotnet/standard/issues/458#issuecomment-323845208
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.
The release notes cover the MVC2 -> MVC3 path. What about RC2 -> RTM? I installed the RTM via Web Platform Installer but looking to the path that System.Web.Mvc reference in my existing project (C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies\System.Web.Mvc.dll) has a date stamp of 1/4/11 so that can't be right.
If i use WPI to install RTM, shouldn't i expect it to have upgraded the RC? Are special steps required in instances where the RC had been installed?
thx
You don't need to do anything to upgrade. The RC2 projects are compatible with RTM. And the file date on disk is probably just the date that you installed Mvc, not he version of the mvc dll
Not sure if there is a question in there.
If you installed a newer version of MVC3 on your machine, you'll need to add a new reference to it in your project. Otherwise, your project will stay on the version of the assembly it currently references to avoid breaking changes.
If you find yourself with a lot of problems keeping your assemblies in an up to date reference, check out Microsoft's NuGet project.
I have just upgraded a solution with two web deployment projects from VS 2008 to 2010 (upgrading all the projects to .net 4.0 as I went).
I installed the new VS2010 web deployment projects to allow me to open my old build projects (these build up my web sites, clean up a few files and zip them for upload).
I've got these working again, but when I look at the built files, all the referenced .net framework files (e.g. System.Web.dll etc) have been included in the deployed site. Does anybody know why this might be happening and how to turn it off?
Maybe you are using a component (DLL) which is using that files probably by needing specific file version of some framework libraries. VS will automatically copy dependencies of a dependency.
It seems you're using .Net framework Client profile version. Please check the .Net framework version selected for upgraded projects under Project properties.
Here is the MSDN article on .Net framework client profile:
http://msdn.microsoft.com/en-us/library/cc656912.aspx
One reason could be the Copy Local = True property of the referenced .net framework files.