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.
Related
Until recently, when creating a .Net Core project, I've been able to select what version of Core to use for it. Since a recent update of Visual Studio 2019, any library project I've created for .Net Core has defaulted to version 3.0. There do not appear to be any options during project creation to select a different version.
For the time being, I need to create projects using .Net Core 2.2, so I'm wondering if anyone knows how to get that option back. For now, I've just been manually changing the target version after creation, but that seems hacky, and I suppose it may be leaving me with bundled references I don't need, or omitting ones that I do.
Update
After installing tons of SDKs, I still do not see the option to choose a framework upon project creation. The documentation for Visual Studio 2019 shows the option as it appears for .NET Framework projects:
... but when creating .NET Core or Standard projects, I am not presented with the option to choose the version:
Is the policy, now, that all projects default to the latest, and if you want something else, you have to change it in the project properties?
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 have a .Net standard 2.0 project in a Visual Studio solution that contains some Azure functions. In the same solution, I've created a .Net Core 2.0 Unit Test project. I've added a project reference from the .Net Core Unit Test project to the .Net standard 2.0 library.
Despite the project reference, Visual Studio is behaving like I'm referencing a dll instead of the project. For example, if I try to use F12/Go to reference, it brings me to a 'From metadata' file instead of the actual code file in the other project. Additionally, codelens features like 'Tested by' (and even just 'referenced by') and the Live Unit testing icons in the .Net Standard project aren't working, since they don't seem to be aware of the Unit Test project at all.
Is there some way to get this integration working between the two projects? My Visual Studio is up to date (15.5.3 enterprise), and I'm not using any tools like Resharper or anything like that.
I'm also facing the same issue but so far the project reference vs dll reference is not the case. I believe this is an existing issue with Azure function projects. There is a thread in Microsoft community regarding this issue. The last comment from Visual Studio is as follows:
I'm closing this report, because in the last 90 days there was no internal developer activity and very small number of new votes or comments. Sorry, we would like to look at this further, but we just don’t have the time right now. Our goal in closing older issues such as this one is to keep customers informed on which issues are currently being pursued by Visual Studio teams. If you still have trouble with our latest version, please report it as a new problem.
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've been writing C/C++ for years using Xcode and am very comfortable with *nix systems. Now I'm working with people who only understand Windows; I've decided to try to learn that environment too.
I was thinking that google would be my best friend, but even the terminology for VS is sufficiently orthogonal to that of Xcode that I can't make any headway. (E.g., what's the equivalent of "Add new Target to project" for VS?)
Can anyone point me to a guide to VS for Xcode practitioners? I've seen lots of translators going the other direction.
Thanks!
I do not know of any XCode to VS Guide, but according to XCode Documentation:
A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.
The analogous concept in Visual Studio would be a project. In Visual Studio, a project contains code files, assets and settings which compile into an output of some sort. (Could be an executable, a DLL, a website, or a few other options...) Projects can reference other projects or other external libraries (System or user libraries) which are all delivered together at compile time.
A solution contains multiple projects which can be related (referenced) and compiled and linked together.
When you first start VS, it will ask you to Open or Create a project. It usually will automatically create a solution and automatically add the project to it. To add additional projects, you can right click the solution in the "Solution Explorer" and add another project.
Hope this helps
I believe what you're looking for is the Build Configuration Manager in Visual Studio. (It's been a while since I've used XCode). As I recall a "Target" in Xcode is how you want the project built. In VS you get a Debug and Release configuration by default but you can use the Build menu and choose "Configuration..." to create more.
I don't know of a tutorial for XCode users but Kate Gregory has some nice beginner screencasts on pluralsight for using Visual Studio 2010. Those may get you over some learning curve hurdles. I think they have a 30 day free trial. If you move on to .NET development they have a lot more that can really help you get up to speed quickly.
Quick Terminology
In Visual Studio you typically create a Solution. A solution can consist of any number of Projects. You can add projects for .DLLs (libraries), services, applications (gui and console based). You can have multiple applications but can only designate one as the Startup Project.
In my typical project I start with the GUI and Add a project of the type I want. Then I often add a library project for new code that I think I can use across multiple applications. Existing code in both supplied libraries and ones you've built are added as References. You can right-click on References in the Solution Explorer and select Add References.
In XCode (when I used it) your IDE consisted of two pieces, XCode and Interface Builder. In Visual Studio you can build interface elements directly in Visual Studio ( but there is also a tool called Blend that allows for UI creation and modification). There are THREE major types of interfaces web (usually an ASP.NET application), WinForms and WPF. I think of WinForms as the equivalent of what you build in IB. WPF is the most recent addition and has lots of advantages but a somewhat steep learning curve.
This is probably oversimplified because VS does so much and I'm mostly familiar with the C# and C++/CLI capabilties. However it also supports Visual F#, Iron Python, Iron Ruby, Visual Basic, Sharepoint, Office Integration,Silverlight, XNA, etc.
Visual Studio is very extensible. There are lots of extensions to make it integrate with other tools. There are also a couple of extremely useful extensions that make refactoring and writing code easier, my personal favorite is ReSharper from JetBrains.