As you are probably aware, Microsoft has deprecated the Portable Class Library (PCL) in Xamarin and replaced it with the .Net Standard class library instead.
I have a couple of older Xamarin projects that use a PCL, but I have started a new project using the .Net Standard class library this week.
Each project needs access to a RestAPI.
A RestAPI could be added to the PCL projects through an easy to use menu as below, and generate the client for me. The .Net Standard project is missing this menu.
Does anyone know how to get this menu back or another way to generate the RestAPI for the .Net Standard projects?
The API for this new project is likely to expand very quickly and change frequently, at least in the early days of development so I wish to avoid having to write it myself (as the Xamarin guide on their site suggests doing).
I am currently using AutoRest to generate the API classes and models to use in Xamarin but i feel this is only a work around as currently to get it to generate correctly I had to use an old version of AutoRest (0.13.0) and an old version of Microsoft.Rest.ClientRuntime(1.8.0) which i copied from a completely different project and run with a BatchFile pointed to a .json file generated from the api.
PCL
.Net Standard
Related
We have a dozen of Asp.Net/WCF applications that we would like to migrate to SDK style. All of them use PackageReference, so that is not a problem.
We do not want to develop our own dotnet build SDK and we are not in a position to migrate to Asp.Net Core/gRPC.
This question is a follow up to Is it possible to use the Microsoft.NET.GenerateAssemblyInfo.targets with a non Sdk style project? - at the end of the day we were able to migrate most of the projects to SDK style and now we want to migrate the WCF/Asp.Net ones.
EDIT
I would like to elaborate on the expectations from such an SDK. As far as I understand, a WCF/Asp.Net project has a few features that have to be addressed:
The publishing logic implemented in Microsoft.WebApplication.targets
The default recognition of certain file extensions. For example, **\.html, **\.css, **\.js should be automatically included as Content, just like in the regular SDK **\.resx are automatically recognized as EmbeddedResource.
Certain assembly references could be added automatically, but this is not a big deal.
Just handling these items would make our day.
If I understand your question correctly..
If you are in position to package your SDK as a new .NET Core dlls / packages while keeping all existing WCF as they are, you could:
Create .NET Core SDK project
Add WCF service references to your SDK project
Allow Visual Studio to generate proxy code
Code against your WCF from the .NET Core calling your services via proxy objects generated
Here is Microsoft team's guidance:
https://learn.microsoft.com/en-us/dotnet/core/additional-tools/wcf-web-service-reference-guide
I converted one of our commonly used libraries to .NET standard 2.0 for mobile application use as well as use in existing applications.
Using this library in an existing Mvc application (4.7.1 Framework) it builds and runs successfully but the Visual Studio IDE reports a list of build errors for the controller classes around not being able to find elements of the library. The using clause of this library is also greyed out in the controller classes.
Is there an easy way to resolve this?
Upgrading from MVC 5.2.3 to 5.2.6 has solved.
Is there a type of c# class library that can be used/referenced by both a UWP (Universal Windows) app and a ASP.NET MVC web application?
I currently have an MVC web application that references a bog standard class library.
When I try to add a reference to that class library from my UWP or Background Application (IoT) projects it complains. I'm sure they would rather have references to Class Library (Universal Windows) project types.
Ideally i'd like a class library that can be referenced by all these project types. I presume this is not possible yet, but I thought i'd ask the question.
Is it possible? I'd rather avoid code duplication.
Do I need some sort of hacky 'include files from another folder' workaround?
Note: I have no intention of moving the web app to ASP.NET core.
I think a portable class library that targets the .NET Framework and UWP should do the job - as long as you don't want to put anything platform specific in it.
2017/18/19 UPDATE:
Creating Portable Class Libraries is now discouraged by Microsoft.
The current preferred method of sharing code between projects targeting different platforms is .NET Standard.
Take a look at the implementation support table shown on the page above. If for example your ASP.NET project is on .NET Framework 4.6.1 or above (preferably on 4.7.1-2), and you are targeting Windows 10.0.16299 with your UWP app, you can make your DLL target .NET Standard 2.0. You can simply reference that class library in both of your projects, just like you'd reference any other library.
I am working on a Windows Service Application. I have several classes in the project and I am trying to put these classes into a ClassLibrary so I can use those classes in the Service App Project, and also in a Console Application Project, so I can run the console version and step through the code. I don't want to re-invent the wheel here...
I have created a Class Library project, and I am having trouble updating the projects in this Solution to use these classes. In fact, when I moved all my classes into the Class Library project, they are all now throwing errors saying, "System" has no member "Data"! My A$$ it doesn't! Pulling my hair out.
Obviously, I have done something wrong. I've been programming since before there WAS a Visual Studio IDE, but this is SEEMING way more complicated than it should be.
Now my Service project cannot reference my Class Library project because the library doesn't have a .dll or .exe extension? I actually have to specify this somewhere, WhereTF do I do this? Isn't this the default behavior of a ClassLibrary? OMG! I just finished an iOS application, and NEVER thought that would be EASIER than a C# app! I did this in VS2010 easily, is 2015 really different?
It should take me no more than 30 minutes to move files from one project in a solution to it's own project, and then add a reference to that new project in the old one. Giving MS a MegaMindWedgie right now..
Don't need portability with RT hardware, just want 32-bit/64-bit computer apps.
All 3 projects are using the same namespace. I can't seem to add any references to the ClassLibrary project like I can in the Service project. It's blank. The only reference available to the Class Library project is .NETStandard,Version=v1.6
HELP...
It looks like you have created .NET Core class library. You can determine this based on the extension of the project file: *.csproj has been used with classic .NET framework projects, and *.xproj was introduced for .NET Core. Most probably, you don't need a .NET Core class library. So, your problem will go away if you create .NET Framework Class Library project.
I wish to write a library that can run on a number of targets such as WPF, Windows Phone/Mobile, Mono, and ASP.NET. I keep searching for information on this but it seems PCL's are not supported in ASP.NET?
Even VS indicates PCL can't be used with ASP.NET:
So what should I do to be able to write a PCL that runs on all the platforms? Use PCL for everything apart from ASP.NET, and create a normal Class Library for ASP.NET and basically copy+paste the code?
The short answer is YES, as long as the PCL profile supports the same .NET framework version your MVC application is targeting, you will be fine.
When you create a Portable Class Library, you can choose a combination of platforms that you want your code to run on. The compatibility choices you make when creating a Portable Class Library are translated into a "Profile” identifier, which describes which platforms the library supports.
What probably confused you, was the fact that ASP.NET was not mentioned in the list of supported software frameworks (platforms). The reason is that ASP.NET is not really a software framework, but an application framework (higher level). This means that whatever application frameworks target the software framework the PCL supports, the application frameworks will also work.
Be sure to take extra caution when choosing the supported platforms when creating a new PCL project, since the API that is available for use in that project depends on that choice!
You can read more about portable class libraries on MSDN.