The IT industry loves to create buzzwords, some new, some are new twists on old things. In .NET Core I read about Packages, References, NuGet Packages, DLL files and Namespaces. I understand the simple basics/steps, but is there a consistent relationship between some/all of the above words?
Does a single Reference ALWAYS point to a single Package?
Is one Package ALWAYS made of one DLL?
Is NuGet Package same as a Package?
What is the relationship between DLL file and Packages? 1 to 1, 1 to many? None?
Creating a Reference - is doing what? Is it pointing to ONE Package or Many?
When I use "Using ABC.123.DEF;", am I creating a new Reference? If not, would I already have created a Reference to that? What does Creating a Reference do, includes the DLLs (other files) in my project, or just tells the compiler to do so at compile time?
Finally, what form does MetaPackage take in Core 3? Is it a NuGet Package?
DLL File
A .dll (Dynamic Linked Library) file is a library that contains code and data that can be used by more than one program, each project that uses it adds a reference to it
Nuget Packages
Put simply, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), when you use Nuget pckage manager console to add packages. if i write a library that would be usefull to other developers, i can publish it to Nuget as a nuget package
Read more about nuget packages
Package Reference
A reference is essentially an entry in a project file that contains the information that Visual Studio needs to locate the component or the service.
for example, if you want to use EntityFramework in your project, you need to install it with the following command
Install-Package EntityFramework
This adds a package reference in the .csproj file
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.1" />
Note: versions may vary
Related
I have a C# solution which contains 3 projects; Application.Server, Application.Client, and Application.Common. Both server and client have a project reference to common.
I want to pack server and client up so that they can be used by other teams in my organisation. I have some automated build pipeline set up that do so, and they publish the nuget packages for server and client. They do not package or publish common. When I inspect the nuget packages, I can see that they reference the common package.
Is there a way that I can get them to build that project into them self? Ideally I don't want to publish the common package as it's pretty specific to my application, and it doesn't really make sense that it's something that's independently consumable by other departments. I also don't want to have to worry about wrangling extra nuget packages if I can help it (as in reality, Common is actually several projects).
If your projects are "old style"/non-SDK/traditional csproj, AND if any project uses a NuGet package, if all those NuGet references are defined using packages.config, then use you can use nuget.exe pack -IncludeReferencedProjects. However, if any of your projects use PackageReference to define their package references (new, SDK-style projects can only use PackageReference), then nuget.exe pack will not correctly create NuGet dependencies for those packages. For SDK style multi-targeting projects, nuget pack will probably completely fail.
The only supported way to pack projects that use PackageReference, or any SDK style project, is to use NuGet's MSBuild pack target (either dotnet pack or msbuild -t:pack). However, this does not have an equivalent to nuget.exe's IncludeReferencedProjects.
If your projects are SDK style, it really shouldn't be any more difficult to create and publish one package or many packages. Simply run dotnet pack on your solution, and every packable project gets packed (remember to mark any class library project you don't want to become a package as not packable). Then use your favourite scripting language to find and publish all nupkg files. For example (Get-ChildItem -Recurse -Filter *.nupkg $SLN_DIR | ForEach-Object { & dotnet nuget push $_ }, or copy/move all nupkgs to a single place (or use the appropriate setting to make NuGet create the packages there in the first place) and use dotnet nuget push *.nupkg.
The NuGet team recommends one package per assembly, and the tooling automatically creates NuGet dependencies for project references, so it all "just works" out of the box. To create a package with all the assemblies included, instead of NuGet dependencies, requires you to do a bunch of work.
I have an assembly that is causing me problems (Sigil v4.7). I can see that it is in my project (via AppDomain.CurrentDomain.GetAssemblies() and Object Browser).
But I can't figure out what NuGet package brought it in.
Visual Studio has a Tree View of packages:
But short of drilling all the way down all of them, I cannot find a way to see which package is causing an assembly to be included in my project.
Is there a way to search to find which NuGet Package caused Sigil 4.7 to be added to my project?
Looks like you can search for dependencies by name in the solution explorer:
If you can't find it there, you can look at the <Project>.deps.json file in the bin\<Configuration>\<Platform> folder.
For example, I have a project called Potato.csproj building in Debug for net core 3.0, so the file is bin\Debug\netcoreapp3.0\Potato.deps.json
It lists all dependencies, as well as what project a dependency came from.
About: I have a ASP.NET website (not Web project) with 3 class library projects in the solution. Earlier I was using SVN but now Git is used source management. I have installed the git locally on a computer (used as server) and using it for merging the source code from other developers. Also, I am using Visual studio 2015 community edition which provides the tools to work with git.
Problem: After cloning the project from the master repository, I build the project to run it. Building the project shows a dialog box saying "Package Restore is in progress". This process creates a folder named "Packages" and that folder includes every package listed in the packages.config file. But after restoration completes, the project throws the following exception:
This exception shows for each package (Autofac here).
The type or namespace name 'Autofac' could not be found (are you missing a using directive or an assembly reference?)
Work around To Solve this problem, I need to uninstall each package and installed it again and problem is solved. This thing I need to do again and again for each developer machine, which is frustrating and time consuming too.
Does anyone has faced the same problem working with Nuget, git and website in ASP.NET.
I faced a problem like this before. In my case, the reason was that I changed the project path (moved the project to another directory), and the path of the packages directory (that contains the NuGet packages) was stored in the csproj file for the old path, that is VS cannot restore NuGet packages. The solution for this was to edit the csproj manually and make it referring to the correct new packages path.
If this doesn't work for you, you can still use your workaround, but using the following PowerShell command (in NuGet Console) for simplicity:
Update-Package -reinstall -Project Your.Project.Name
Note: project name doesn't contain csproj extension, just the project name
It is good practice to not put third party packages into source control. It bloats your repository (even on a large web application, the size of the external packages will massively out weigh your code).
If NuGet package restore is slow, you could look at using a local cache (this can be as simple as a shared folder) or a better internet connection.
That said, you should only have this problem once per machine. While the packages are downloading you could be giving the new team member an overview of the design…
Make sure that all of your projects are using the same target framework, when this isn't done you can often get the
type or namespace [name] could not be found
warning.
To do this, right click each of the projects in the solution explorer > Properties > Application tab > Target Framework. They should all be the same or there will be incompatibilities between the references in your projects. Here's a question regarding this, hopefully this helps.
The main reason is there no Autofac reference in packages.config file.
When you see on the screen Restore packages message box this mean that nuget package manager is trying to install all the packages which are missing in the package folder.
Try to do this step:
In Visual Studio Solution Explorer pick the project and via context menu pick Unload project
After project was unloaded via context menu pick Edit your project
Go to section group and find you Autofac Reference section
If HintPath doesnt looks like ..\packages\Autofac.4.1.1\lib\net45\Autofac.dll (Actual for 4.1.1 version) remove the Autofac reference Item
Save csproj file and reload project
Install Autofac via NuGet Package manager
Commit and push changes to git repository
Had the same problem with VS 2019. In ASP.NET, packages are updated via the .refresh files that appear in your bin folders. If these aren't checked into Git, they wouldn't be copied down to your cloned repro.
I added the .refresh files for all of my package dlls, made sure the versions and paths in the .refresh files were correct, and now everything updates as expected.
I created a new asp.net project, and I am using the monodevelop as the ide.
On the left hand side in the explorer I can see two sections, one is called reference and the other called packages.
I assume that references are the library or dependency files like the jar equivalent of java. Then what are the packages section for?
Is it also another kind of dependency?
Can anybody help me understand the meaning of those two sections?
I assume you mean References and Packages. There is no Resources section/folder when I create an ASP.NET project in MonoDevelop.
The References folder will show the assemblies that are being referenced by your project. An assembly is equivalent to a jar file.
The Packages folder shows you the NuGet packages that are being used by your project. A NuGet package will typically provide assemblies and these will be shown inside the References folder but within a From Packages folder. A NuGet package may include other things, such as content files, which are added to the project, or custom MSBuild targets which modify the build behaviour.
I have created a project in VS2015, structure as below:
Solution1
BookStore.ClassLibrary1 => Class Library (Package)
BookStore.ClassLibrary2 => Class Library
BookStore.Web => MVC5
In BookStore.Web, I can reference BookStore.ClassLibrary2, but fail to reference BookStore.ClassLibrary1.
It shows an error "A reference to 'ClassLibrary1' could not be added."
My question is how to reference a Class Library (Package) in VS2015? Thank you so much!
Looks like your ClassLibrary1 project is a Class Library Package, not a class library project. Class Library Package is used to create Nuget packages that can target any platform.
There are a number of benefits of ASP.NET 5 Class Library projects (.kproj) over Class Library projects (.csproj):
ASP.NET 5 class libraries easily support cross-compiling projects to multiple targets, such as aspnet50, aspnetcore50, net45, and various other portable class library variations. This includes rich Visual Studio support for Intellisense to notify you which APIs are available for which targets.
NuGet packages are automatically created, which is an extremely common thing to do with class libraries.
Better productivity when it comes to things like automatically refreshing Solution Explorer when the file system changes. Fewer conflicts in source control when trying to merge conflicting changes in the *.csproj file.
Can be compiled cross-platform (in part because it doesn't depend on MSBuild)
You can reference a *.csproj project from a *.kproj project (this was just made a lot easier with the new preview of Visual Studio 2015), but it was always possible with some manual steps.
Why does the name have "ASP.NET" in it?
As far as the names goes, it's a relic of history that will soon be addressed. The new project type is useful far beyond ASP.NET 5 applications. Expect to see new names in a future preview of Visual Studio:
.NET Console Application (Cross-platform)
.NET Class Library (Cross-platform)
With the release of Visual Studio 2015 RC you can see the updated project template names:
Class Library (Package)
Console Application (Package)
These use the project.json file and the .NET Execution Environment (DNX) to build, run, and package (into a NuGet package) the project.
These project templates continue to show up in the New Project dialog under the "Web" node, but now also show up in the main "Visual C#" node as well.
Here is a good link as you need to referance a dll that the new clas library does not build. https://evolpin.wordpress.com/2015/01/25/vnext-and-class-libraries/
Either use a plain old class library or use a Nuget class library, publish it to a local or public Nuget repo and add it to the web project from there.
I doubt about dependency of ClassLibrary1 and I can even see that in your screenshot,
It seems ClassLibrary1 is looking for some dependent dlls, so you might need to add those dll first then you can go ahead and add it.
Something similar happens here too
More details about Depencies can gather from this MSDN link you can directly jump to Dependencies node for Bower and NPM dependencies