When creating a new Visual Studio 2015 class library (package) project, one is able to set multiple target frameworks.
What is the difference between dotnet and net452?
project.json:
"frameworks": {
"dotnet": { },
"net452": {}
}
Project layout:
dotnet:
The new .NET Core for packages that don’t have any app model requirement, this is the runtime. (You could also use use dnx or dnxcore for example)
net452:
This need to be referenced if you want something that is only part of the full .net framework.
Oren Novotny has a great blog post explaining it.
I cannot answer to the previous answer from thllbrg (which is roughly right ... Also Oren blog post is the most important source at the current time), but one important clarification: dotnet does not have a runtime.
Libraries build with dotnet can deploy the DNX, .Net Framework and the UWP platforms (if the dependencies of your libraries allow so). All have different CLRs and compilation models. DNX e.g. support compilation on the fly, while UWP compiles ahead of time into one file and does tree shaking (the killing of not used functions in your library).
Related
I work with Xamarin.Forms in Visual Studio since a few years, and updated my IDE recently (VS v. 16.3.7). Now I realized something is missing: the Shared Project option.
When i go through the Wizard to create a new project the question if I want to use Shared Project or PCL(or NetStandard) is now missing (see screenshot below from VS 2017)
I do know that you can still create a Shared Project and add an iOS and an Android project manually, but this is just too cumbersome. My question really is: Is there a reason why Microsoft went on to push the PCL/NetStandard above the Shared Project strategy?
I am specially confused about this decision since already back in 2016 #miguel.de.icaza declared his favorite option (for most cases) was the Shared Project strategy:
https://tirania.org/blog/archive/2016/Jan-22.html
For me, the PCL is just too cumbersome for most uses. It is like using a canon to kill a fly. It imposes too many limitations (limited API surface), forces you to jump through hoops to achieve some very basic tasks.
I have installed VS 2017 15.9.14, on this version, Portable Class Libraries (PCLs) are deprecated. You could use .NET Standard instead. On VS 2019, the default is .NET Standard.
On Microsoft document, MS recommend .NET Standard 2.0 libraries over Portable Class Libraries.
For more, please refer to the MS docs. https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
My question really is: Is there a reason why Microsoft went on to push the PCL above the Shared Project strategy?
For MS announcement, PCL is deprecated, you could not find that when you create the project.
You could create the Shared project by File > New > Project > Shared Project template.
For more details, you could check the link below. https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/shared-projects?tabs=windows
Updated:
Is there a reason why Microsoft went on to push the >NetStandard< above the Shared Project strategy?".
For the old version of VS 2017, .Net Standard is an option of Shared Project strategy.For the latest version of VS, MS use .Net Standard as the default for Sharing Strategy.
Is there any doc where MS states why Shared Project is now deprecated/not available in the Xamarin.Forms project wizard?
PCL is deprecated. Shared Project is still in use, in my answer, I provide the second link about how to create the shared project.
Summarizing and adding to the answer by #WendyZang-MSFT:
I started a project using the Shared Project strategy around 4 years ago, and until now i have not found any issue/problem specific to it that would make me consider moving to .Net Standard.
Recently i went into the trouble of localization, and even that was possible using Shared Project without much hassle.
As mentioned above, after i saw that the latest version of Visual Studio 2019 was not offering the possibility of creating a Xamarin.Forms App as a Shared Project i got a bit worried thinking that i should migrate my solution. But the time hast passed by, and i just realized that MS encourages the use of .Net Standard, but Shared Project remains also a valid approach.
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.
My Xamarin.Forms project targets PCL profile 259. I recently read a lot of moving to .NET Standard, but it looks very painful to do.
Currently I develop in Visual Studio 2015 Update 3. But will give VS 2017 a try soon.
My solution consists of:
Common PCL library
Android specific project
iOS specific project
My Questions:
How can I convert from Profile 259 to latest .NET Standard?
Is there some official converson guide from Xamarin / Microsoft Team already available?
My Xamarin.Forms Android and iOS Apps are built in VSTS. Does VSTS support .NET Standard or would I end up in build errors?
Thanks in advance for any good solution.
To change a PCL to .NET Standard you just need to go to the Properties of your PCL and select Target .NET Standard Platform
Then create a project.json file, if it didn't already create one for you and insert the following.
{
"supports": {},
"dependencies": {
"NETStandard.Library": "1.6.0",
"Xamarin.Forms": "2.3.4.192-pre2"
},
"frameworks": {
"netstandard1.3": {
"imports": "portable-net45+win8+wpa81"
}
}
}
You need the imports to allow non .NET Standard libraries to be added.
In VS 2017 it gets different. While the above will continue to work, you can have a full .NET Standard library as a csproj (no longer an xproj), and have it happily work with Xamarin.
However, there is no automatic conversion (that I know of), so what I normally do, is edit the csproj and completely replace it with the following. Just delete everything in that file and put the following.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3</TargetFramework>
<AssemblyName>MyLibraryName</AssemblyName>
<PackageId>MyLibraryName</PackageId>
<NetStandardImplicitPackageVersion>1.6.0</NetStandardImplicitPackageVersion>
<PackageTargetFallback>$(PackageTargetFallback);portable-win+net45+wp8+win81+wpa8</PackageTargetFallback>
</PropertyGroup>
</Project>
You will then have to add your references and NuGet packages manually, again. With the PackageTargetFallback, this line is similar to the imports in project.json.
In regards to VSTS, I know that the first method with VS2015 works just fine, as I have done it myself. The VS2017 method should work with VSTS, however I haven't personally tried that just yet.
I see that MS has documentation on how to implement nesting projects when implementing new project types. While this looks do-able, I'd rather not write and maintain my own VS extension if I can avoid doing so. Is there any "generic" project type already implemented by some extension that will allow project nesting? The idea would be that the parent project does nothing but include its children and allow building, adding references, etc.
Managed Package Framework for Projects is for Visual Studio 2013 and includes "a project system that supports nesting" (see the NestedProject sample). I have not tried it myself, though I did look through it a while back (the VS 2010 version) and it has thorough documentation.
It may or may not be as extensive as what you are looking for. From the overview in the documentation:
Creating a new project type in Visual Studio is complex task. Using MPF_Proj is a good starting point for creating custom project types in Visual Studio written in managed code but there are limitations that would have to be considered before using the framework.
MPF_Proj is not a .NET library. It is rather a framework of source files (classes, utilities etc.) that can be included in a VSPackage project.
I'm confused. We upgraded our project recently to .NET 4.5.1. We installed .NET 4.5.1 on our servers.
I'm referencing assembly System.Threading.Tasks.Dataflow from the GAC at C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Threading.Tasks.Dataflow\v4.0_4.5.9.0__b03f5f7f11d50a3a\System.Threading.Tasks.Dataflow.dll
CopyLocal is set to false as (I assume) it's part of the Framework, so should be already installed wherever the app is deployed.
The trouble is, when running on the server, it says it can't find this assembly.
I've read here that is is part of .NET Framework 4.5:
but the library is now built-in with .NET 4.5.
...and I've read here that it isn't!
The TPL Dataflow Library (System.Threading.Tasks.Dataflow namespace) is not distributed with the .NET Framework 4.5
What gives? It doesn't look like it is. Is it just part of the 'targetting pack'? Is it me, or are these in-place upgrades more agro than they're worth?!
I'm not sure why that page says it is part of .NET 4.5 -- it's still an out-of-band NuGet release, like Entity Framework, MVC, etc.
I recognize this question is pretty old, but I wanted to add my solution as well. I found adding the below two items to the Visual Studio 2019 install (run Visual Studio Installer > Modify > .Net Desktop Development) the problem went away and it was able to pull System.Threading.Tasks.Dataflow from the GAC.
Edit: Installing Visual Studio 2015 also seemed to be required. Obviously it isn't VS 2015 itself, just something it comes with. But there are too many packages for me to figure out which one easily.
Edit2: This isn't really the best solution, more of a stopgap. MS suggests downloading it through Nuget. https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.dataflow?view=netcore-3.1
The TPL Dataflow Library (the System.Threading.Tasks.Dataflow namespace) is not distributed with .NET. To install the System.Threading.Tasks.Dataflow namespace in Visual Studio, open your project, choose Manage NuGet Packages from the Project menu...