.NET Core/Standard 2.0 now lets you reference old .NET Framework libraries. You can install them via NuGet, and the code will build. This works within limits though:
"The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set." -- Announcing .NET Core 2.0
When using Topshelf from a .NET Core 2.0 application, I get the following exception:
There seems to be a dependency on System.ServiceProcess.ServiceAccount that is not satisfied. Is this dependency available within the .NET Standard 2.0 spec at all? If not, is there any other way I can get this to work?
TopShelf does not work on .NET Core 2.0 because it is missing some other fundamental APIs as well (most prominent one would be ServiceBase). Some missing types are being developed as NuGet packages for the 2.1 timeframe but this does not mean that TopShelf is instantly going to work. You can follow TopShelf's GitHub issue for .NET Core support for details and updates and even some replacement libraries for basic functionality if you must run on .NET Core until TopShelf will be able to work on .NET Core (basis of which I have written).
Related
I'm decided to migrate from .Net classic web api project to .Net core project. Many developers say to me for migration you don't have any concern about code changes, because .net core support package for Ninject, but I don't see any operational example. Please tell me exactly could I use my old api controller from .net classic project in .net core project using Ninject?
ASP.NET core comes with completly new web framework. Regarding your existing controllers from classic web api framework, you can do the following:
rewrite them to fit the new framework
or use Microsoft.AspNetCore.Mvc.WebApiCompatShim, so you can reuse them
Here is the article describing this topic:
https://learn.microsoft.com/en-us/aspnet/core/migration/webapi?view=aspnetcore-2.2
What you don't have to rewrite are dependencies that can be ported to .nestandard. This is also the case of Ninject, because it already supports .nestandard, so if you've already written any Ninject modules you can use them. But the integration with the ASP.NET core looks different, beacause the framework is different. As already commented this link shows the integration:
How to integrate Ninject into ASP.NET Core 2.0 Web applications?
I have visual studio 2015 professional editton, and i want to create my first MVC web application which should be a .net core. now i am watching an online learning demo, which mentioned to create this project:-
while inside my visual studio i have these options:-
so which option i need to chose?
second question, how i can be sure that i am using the latest version of MVC?
Thanks
First, there is no such thing as MVC 6. It's ASP.NET Core. Second, the decision of whether to use .NET Core or .NET Framework comes down to what you need to do. .NET Core is cross-platform (Windows, Mac and Linux), whereas .NET Framework is Windows-only. .NET Core is also lighter weight, faster, and has a number of new CLR features, compared to .NET Framework. Virtually the only reason to use .NET Framework is if you have a dependency on something that utilizes Windows-specific APIs, meaning it can't be run cross-platform. Otherwise, you should always use .NET Core, if you can get away with it.
ASP.NET Core is really just a collection of NuGet packages, and like other NuGet packages, they can be updated easily. However, the difference is that these NuGet packages are generally tied to a particular version of .NET Core, and thus, the appropriate version of the packages are installed based on which version of .NET Core you're targeting. For example, if you're targeting netcoreapp2.2 then you'll see that that packages like Microsoft.AspNetCore.App will be brought in with versions like 2.2.x.
So, to answer your question about staying up to date, it essentially entails installing the latest version of the .NET Core SDK, and then changing your project to target that new version. Then, all the ASP.NET Core NuGet packages will naturally update accordingly.
I have a few simple questions:
a) can I use mono on linux and osx to load the full .net framework like I would on windows by adding net46 to my project.json?
b) can I use mono as an alias like net46?
c) can I use mono with aspnet core 1.0 rtm projects on linux?
I have been looking at the dotnet docs, specifically the standard library and the table and the table with the platform support confuses me with the arrows and star under mono.
thanks
can I use mono on linux and osx to load the full .net framework like I would on windows by adding net46 to my project.json?
In theory, yes, that's exactly what you do: specify some version of net inside frameworks in your project.json and dotnet run will then use mono to run your application.
In practice, basic Hello World application works, but I'm not sure how well will more complicated applications work.
If you want to run dotnet build on the same machine, you will also need reference assemblies. The version I tested (mono 4.2.1) only contained reference assemblies up to .Net 4.5.1, so net451 works, but net46 doesn't.
can I use mono as an alias like net46?
I don't think you can, at least not without forking .Net Core SDK.
I don't understand why would you want to do that, but I believe doing so would require modifying DefaultFrameworkMappings in NuGet.Client.
can I use mono with aspnet core 1.0 rtm projects on linux?
I wasn't able to make a basic ASP.NET Core application run under mono. I don't know what the problem is, or how hard would it be to fix it. EDIT: I managed to work around the issue I encountered.
Mono is other thing. Yeah they developed mono like .net framework but you cannot use .net 4.6 on mono.
Read the following article. Click here
Micrsoft developed .net core a new framework to run .net on windows, linux, mac osx etc.
This issue is exactly as described in the title.
I have a portable F# class library. I have created an ASP.NET Core Web Application (both .NET Framework and .NET Core), from which I have tried to add a reference to my F# class library.
Trying to add the reference gives a message:
The following projects are not supported as references:
Project type is unsupported by current project and can not (sic) be referenced.
This is extremely disappointing, as the .NET Core is now in General Availability.
Are there any workarounds while this bug gets addressed?
I have a project, which I started with Beta8 bits of .net core and since then I have an F# library, which I use from an asp.net core C# app. (btw here is an RC2 based minimal sample for referencing the F# lib from a net core based console app)
Here is how I did it:
Currently (according to my knowledge) there is no template in VS to create a coreCLR based F# library (the PLC templates under F# are all Full framework based, but that you still cannot reference from asp.net core even if it runs on full framework), so you have to do this with the command line. This is done by:
dotnet new --lang F#
This creates you a hello world coreCLR F# app. You can turn the app into a class library by modifying project.json file.
If you have a VS solution and you click to “Add” -> “Existing project” you can select the project.json file. This way you add it to your solution (and btw. an xproj file will be also created).
So at this point you will have the coreCLR based F# project in your solution. I believe by right clicking the asp.net core project and go to “Add” -> “Reference” -> Projects->Solutions and selecting the F# library you can already reference it. If this does not work, you can do it manually: just list the F# project under the “dependencies” in the project.json of the asp.net core application.
If your asp.net core app runs on full framework still need to do these steps. It actually doesn't really matter.
Now the bad part:
In the RTM (released on Monday) the “dotnet new” command creates an uncompliable F# app, because of some dependency issues. This is tracked here (the title says "on macOS", but it's the same on Windows) and as soon as it’s solved this should be fine (or if you did not yet install RTM and you have RC2 you are also good).
Intellisense and debugging across F# and C# does not work (I posted it here)
Although .NET Core has officially been released, the vast majority of the nuget packages in the ASP.NET Core Web Application are in prerelease. Moreover, although the entity framework identity model has been cleaned up, my attempt to change the key columns for users and roles from strings to ints generated an obscure error when I tried to implement Entity Framework migrations. I know I can do it for a .NET Web Application, even though the process is clunky in places. So for now I have gone back to using a .NET Framework Web Application. I'm looking forward to seeing a fully mature version of ASP.NET Core Web Applications. It's not ready, but it looks very promising.
We have a large system of .net framework 3.5, but seems that z3 4.0 C# API is only meant for .net framework 4.0. Is there anyway for our system to use that API without upgrading the .net framework version currently (it is quite hard to do so)?
The current code for the .NET interface requires .NET 4.0 because it depends on some features that were first introduced in this release (e.g., System.Numerics and System.Collections.Concurrent). Upgrading to 4.0 should not be a major problem though, and it is only required for the top-level application as it should be backwards-compatible with other components that were compiled for the 3.5 framework (with few exceptions, see MSDN .NET version compatibility).
If your code does not require BigIntegers, it would be possible to work around these issues for us; I could create a "special edition" just for you. There is some effort involved with this though, and there would be no future updates, so we should only consider this if it is absolutely necessary.
We are currently looking into the possibility of releasing the source code of the .NET API, so in the future such adapdations and modifications can be done by end-users themselves. Until that is the case, I would request interested users to contact myself directly so we can discuss "special editions" on a case-by-case basis.