I created a simple Web API project in Visual Studio 2015 using the .NET Core Framework. When I publish this project using the default settings, it creates the following:
In total there are 155 DLLs, 77 in the PublishOutput root and 78 in the refs folder.
Why put all the DLLs in the publish folder? Couldn't it just
reference the DLLs where they were installed from a single shared
location ?
Dotnet core tend to be very minimal as opposed to the previous versions of .net framework.
In dotnet core, the main purpose was making the core framework as small as possible and if you need more stuff, bring it in through NuGet packages.
So, many dependencies that used to be available in the framework are now moved to the NuGet packages and as you know there is a chain of dependencies in NuGet packages, so we will end up with so many libraries in our publish output, which is fine.
Another point being, most of the time, we're using project templates with too many dependencies that might not be needed whatsoever. So we can either start with a very minimal template and add needed stuff in it, or remove useless stuff from a more chuncky template.
I had a similar issue. When my local computer was upgraded from Net Core 2.0 to 2.1, my Core We Application which references a NetStandard application started publishing all DLL's in all referenced projects. I migrated my Core 2.0 application to 2.1 to match the highest version of SDK installed on my local and I could see my issue is now resolved. Publishing from the migrated(upgraded) application produced only the required DLL's. Hope this helps.
Related
I was developing an ASP.Net Core Web Api together with dlls specyfic to the domain. I have also developed a dll which turned out to be the one that can be shared across organization as NuGet dll. I created that dll in the same solution where i have my AspNet Core app. In consequence each time I run a build, version of this Nuget is bumbed up even if no changes were made to that dll.
I have 2 questions:
Should I move this Nuget dll to separate repository? Is this a best practice?
Can i somehow configure a task in AzureDevops pipeline in a way that version should be bumped only when there is a change made to that dll?
Should I move this Nuget dll to separate repository? Is this a best practice?
It depends on your actual application. If the project of this NuGet dll in the solution is independent and not related to other projects. The best practice is to move this Nuget dll to separate repository.
This helps to manage the shared nuget dll.
Can i somehow configure a task in AzureDevops pipeline in a way that version should be bumped only when there is a change made to that
dll?
AFAIK, there is no such task to achieve this. But we could try to modify current pipeline to only build AspNet Core app project instead of the solution, and create a new pipeline only build the nuget dll project and give the path filter:
In this case, each time run a build, version of this Nuget is bumbed up only changes were made to that nuget dll project.
I know nuget.org does not have this functionality yet, but I have been searching for release notes on the nuget package developer websites, and this is taking longer than expected, since I have a lot of nuget packages installed on my .net framework project.
Is there a better way to do this? maybe someone has already done it and posted a list somewhere?
thanks in advance
If you change the 'n' in the nuget URL to an 'f', so it becomes fuget, you'll get a list of which frameworks the package targets. If you see it targets a netstandard version then it will work with .NET Core.
If your project is using an "old" style csproj with packages.config, the first step is to migrate to using PackageReference instead. Here's some docs. As the docs say, there are some differences between how packages.config and PackageReference works. If you're affected, you're blocked until you can make your project work with PackageReference.
If your project is using an "old" style csproj with PackageReference (for example you did the migration above), then migrate to SDK-based csproj so you can build with the dotnet CLI. Here's a blog post with details how to do it.. Note you you can keep using the Windows .NET Framework with SDK csproj. Although SDK-based csproj came out at the same time as .NET Core, it's not necessary to use .NET Core with the new project style. If your project is a class library or console app, you're definitely fine, otherwise you need to research to find out if the project type is compatible with SDK projects or not.
Once you have your .NET Framework project working with SDK projects, either change the TargetFramework to netcoreapp or netstandard, or you can multi-target your project by changing TargetFramework to TargetFrameworks, and use a semi-colon separated list of TFMs you want to target. For example <TargetFrameworks>net461;netcoreapp2.1</TargetFrameworks>. Then simply run dotnet restore and if any of the packages you use is not compatible with .NET Core, restore will fail, and you simply revert to target only .NET Framework.
In summary, once your project uses SDK-based csproj, it takes 10 seconds to test if your dependencies are compatible with .NET Standard/.NET Core. If your project is not yet using SDK-based csproj, you undo your change to the TargetFramework(s) line in your csproj and continue with your life until the next time you test again. If you're not already on SDK-based csproj and there's nothing blocking you from doing so, then doing the upgrade is low risk and bring some benefits, such as fewer merge conflicts on the file, much easier to create nupkgs for any packages you maintain, and being able to test against .NET Core compatibility in seconds.
Alternative: If you're unable or unwilling to migrate to SDK-based projects and you want to check if your dependencies are compatible, then use dotnet new classlib to create a new .NET Core project, add package references to the same packages that your existing project uses, then try to restore. If you have a big solution with lots of projects and/or references, just write a small program to read your packages.config/csproj files as XML, find unique list of packages that you use, then write a new SDK-based csproj targeting .NET Core with all the packages you just found as package references.
In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.
I have a ASP.NET Core 1.0 MVC app in solution X and I have some common projects (.net 4.5.2 class libs) in solution Y.
I want to reference the projects in solution Y from my app, when I do so via add reference -> Browse .. I get:
.NET Core projects only support referencing .NET framework assemblies in
this release. To reference other assemblies,
they need to be included in a NuGet package and reference that package.
I then created a nuget package of those projects, added the folder that contains the nuget packages as a repo source and loaded the projects. This adds the projects successfully to my project.json, but 'nothing' else actually happens, I still can't use the code in my app.
Now ASP.NET Core is past its beta status, what is the official way of dealing with this?
Many people have struggled with this issue and there is a long running thread on GitHub about it. Even the people using the latest RC3 build are reporting the same problem that you are having.
The only way I've been able to reference class library projects in an ASP.NET Core web application is to create both the web application and the class library projects in Visual Studio 2015 Update 2. And they all have to target .NET Framework 4.6.1.
I had to copy the code from my old class library projects to the new ones. But in the end I think I saved myself time by not having to mess with all the workarounds that don't seem to work for a lot of people.
In this video, Scott Hanselman interviews a guy from the ASP.NET team. He says that one of the goals of ASP.NET 5, on top of .NET Core, is that the apps won't depend on the .NET Framework and GAC assemblies on the hosting server. Instead, .NET Core libraries will be released via NuGet packages and apps will be deployed with their dependencies.
One of the reasons for this is so Microsoft can quickly release a bug fix or new feature, and we don't have to wait until the new version (of the full framework) is installed on our hosting environment.
My question is:
Are the apps built on .NET Core really independent of the version of .NET installed on the target machine, and can they run even without the .NET Framework installed?
Yes, the framework you use in your application is completely independent of the .NET Framework installed on the target server, because the Core .NET Framework is referenced via NuGet packages and can be bundled up for deployment via the DNX Utility, specifically of interest to you will be the dnu publish command.
Here is an excerpt, describing what dnu publish does:
Publish (dnu publish)
The publish command will package your application into a self-contained directory that can be launched. It will create the following directory structure:
output/
output/packages
output/appName
output/commandName.cmd
The packages directory contains all the packages your application needs to run.
The appName directory will contain all of your applications code, if you have project references they will appear as their own directory with code at this level as well.
So the .NET Core will exist in the output/packages directory and will not need to be installed on the target server.
A normal .net core app requires that you install .net core on the machine you wish to run the application on. There is a way to avoid this however, by publishing a self contained app. You can publish your app with the requisite version of .net core included. This will make your app larger, but if you only need one application on a machine to run .net, you need a specific version of .net, or you want to make a portable application, this is a good choice.