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.
Related
I have a solution with a number of projects.
I have changed system.Net.http to use the NuGet version, and most projects, when i select the "System.Net.Http" reference in the references node of solution explorer, it shows the path as "X:\myPath\packages\System.Net.Http.4.3.4\lib etc..."
However, i have a couple of projects when removing reference to System.Net.Http then going to NuGet Package Manager and installing it, when you click reference in the reference node, the path shows as "C:\Program Files etc.... Microsoft.NET.Build.Extensions\net461\"
I have opened the project file, and the "HintPath" is correct, however the path that shows in the reference Properties is incorrect.
When i look at Object Browser, it confirms this project is actually calling the framework version of System.Http.Net (so, even though i have installed NuGet version, and the HintPath is pointing to our packages folder, its still referencing the framework version)
Does anyone know why the path isnt matching and how I can fix this (so my project is using NuGet version instead of framework version to match the other projects in my solution?
Just incase it helps, here are all the references in the problem project:
I have a theory: it's a hack implemented in Visual Studio in order to workaround an issue with the package System.Net.Http.
There are issues with this package and it seems we should not use it anymore. The version of the System.Net.Http library included in the .NET Framework is better starting from 4.7.2 if I understand correctly.
See:
https://github.com/dotnet/corefx/issues/11100
https://github.com/dotnet/corefx/issues/17522#issuecomment-338418610
https://github.com/dotnet/corefx/issues/29622
I'm currently moving projects to .NET Framework 4.8 and I'm removing all System.Net.Http packages.
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.
When i create an empty ASP.NET Web Application (.NET Framework) project with VS 2017 and install the bootstrap.saas nuget package (https://www.nuget.org/packages/bootstrap.sass), the package integrates within the project structure and the Content and Scripts folders are being created.
As the folders are within the project folder, i can easily work with them like compile them and minify them and copy the results into my wwwroot folder.
But when i create an empty ASP.NET Web Application (.NET Core) project with VS 2017 and install the bootstrap.saas nuget package, the package lands in the global nuget cache in the C:\Users\USER_NAME.nuget\packages\bootstrap.sass\4.0.0-alpha6\content folder and not in the project folder.
What is the best workflow/practice here to work with the nuget cache files and get them compiled and minified to the wwwroot folder within the .NET Core project?
Can i force nuget with an additional NuGet.Config file inside my project to install the package within my project folder or subfolder? Are there other options?
I know that i can use npm/webpack/gulp etc. for that but would like to do it the "old" way how Web Extension Pack did it for VS 2015 and like the Web Compiler (both from Mads Kristensen) do it now for VS 2017. Or do i run into a dead end using the Web Compiler?
Thanks
Can i force nuget with an additional NuGet.Config file inside my project to install the package within my project folder or subfolder? Are there other options?
If you want to change packages default location for .net core project, you can set "NUGET_PACKAGES" environment variable. Just Set "NUGET_PACKAGES" = "c:\teampackages". Or you can place a NuGet.Config file next to the solution with the following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="globalPackagesFolder" value=".\packages" />
</config>
</configuration>
For the detail info, you can refer to this document and the same issue on GitHub.
However, what I want to say is that you might not be happy with the results.
Because .Net Core projects rely on so many NuGet packages. Almost hovering around 1GB. I think you will not want to set all those packages for each solution. Besides, with this change, you need to set up additional sources in VS for every solution. It`s quite inconvenient for .net core project.
This is the reason why NuGet team set the special settings for .net core projects. So how about add the Content and Scripts folders manually? It would not be very difficult.
Hope this can help you.
I'm trying to do something with .NET core in VS2017 RC, but I noticed the packages.config is missing, because they default in defining dependency in the project file.
However my configuration look like this:
so apparently it should use the file. Apparently it does not honour that configuration.
Furthermore,
Is there some reason we should prefer the dependency in the project file anyway?
In previous versions of .net the csproj contained an assembly reference to a DLL that was stored inside a package. However that was treated seperately, from the packages.config which declared the packages to restore into the packages directory.
In dotnet core, packages are declared inside of the csproj file, as "PackageReference" The overall idea of a packages.config does not exist in dotnet core, which is why visual studio is not trying to create one for you. If you were using the old project system, you will find a packages.config is created for you.
That setting you set won't be honored by .NET Core projects.
.NET Core always uses the package reference. So say goodbye to package.config.
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.