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.
Related
Background:
I have several ASP.NET projects under one solution file. I have a build pipeline for ASP.NET projects and building it with .sln.
Now, we have added a new project to the same .sln which is in .NET CORE.
Problem statement:
In my build pipeline, when I try to build the whole solution, it throws an exception to the newly added project. (.NET CORE)
"The type or namespace name 'Entity' does not exist in the namespace
'System.Data' (are you missing an assembly reference?)"
I believe this is due to framework versions.
Question:
Is it possible to have both projects under one build pipeline, if yes, how can I achieve it? if not, what would be the ideal solution?
Additional information: From the visual studio, everything is building and working fine, but I build the project pipeline it's throwing this error.
Initially build the code from visual studio to avoid errors while building in the azure pipeline.
Used different projects in azure pipeline
Create a repository using Visual Studio or Azure Devops.
Fill the necessary fields while creating a repository
Then it enters into a Git Credential Manager screen and have to choose the account from which you want to create and proceed further.
Create branches if required.
Using Visual Studio, we can sync and push the changes made from the specific branch
Create a pipeline with azure subscription and build the code.
Refer this link for more info.
You could add a reference to System.Data.Entity to test if the exception is thrown again.
Or you could refer to this document for more details about Organize your project to support both .NET Framework and .NET
================================================================
updated on 11/30
This error message indicates the build process can't find the assemblies coming from the restored nuget packages. So you should check the log of the restore task in build-pipeline to make sure the packages are restored successfully.
Make sure you have use nuget tool install and nuget restore tasks before your build task like this, if your build include private feed, please add the nuget authenticate task to restore the project correctly. (Avoid using dotnet related tasks cause your project targets .net framework, and dotnet task could not recognize .sln projects)
I was able to resolve this by updating the NuGet package version for the pipeline. Same as the application version.
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.
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.
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.
I have a webforms projects with entity framework 5 and .NET 4.5. When I'm publishing the the web site it generates 'packages' directory in the compiled code, with some entity framework dll's in it. However the website functions well even If I remove it. It should be mentioned that I don't use code-first.
What is the purpose of this folder?
TIA.
First, make sure you're using EF5, as version 5.0, not the 4.4 that may happen if you first installed the EF5 on .net 4 and updated to .net 4.5 later.
http://thedatafarm.com/data-access/when-entity-framework-5-ef5-is-not-entity-framework-5-ef5/
From EF5 on, entity framework is a separate api(package) that can be installed via Library Package Manager or NuGet from Visual Studio, it is not part of .net framework installation any more.
packages folder is a default one for NuGet package installation.
So, please have a look at the EntityFramework reference that must be present in your project where you actually work with EF, and see the version and the location of assembly you are referencing. If your Copy Local property is set to true, you don't need to include packages folder in your installation package, assembly will be copied to bin folder automatically, otherwise you'll have to.
The short answer to your question is : No, you don't need the packages folder
Long answer : No, you don't need the packages folder in production, its created by nuget when you install a package to hold the dlls for that package.
So if you include EF in your project it will be copied in there and a reference will be added to your project to ~/packages/Entityframework.dll, at compile time a copy of the dll will be put in your bin folder.
During releases to our live environment I routinely remove this folder as its not needed.