asp.net core 2.2 publish generating lots off DLL in output directory(bin\Release\netcoreapp2.2\publish).
How I can move it to some other folder (bin\Release\netcoreapp2.2\publish\lib) & reference it?
Your question doesn't really make sense, but I imagine you're looking for a way to include a library from one solution in another. This is not the way to do that.
Instead, package your project as a NuGet. Then, you can reference the NuGet package in your other solution's projects. Some people are confused and think creating NuGet packages means having to make them public on the main NuGet repository. While you can of course do that, it's not required. You have a private repo, either through a third-party or deploy your own, or you can simply use a filesystem path or network location as a "repo".
In any case, creating a NuGet package is simple. You simply edit your project properties, go to the "Package" tab, and enable NuGet package creation. Fill in the relevant details about your package on that screen, and you're off to the races. Whenever you build or publish your project, you'll get a NuGet package created in the same directory. Then, just push that to your NuGet repo, or if it's a filesystem path or network location, copy it there.
Related
I have install some asp.net core mvc dlls (Microsoft.AspNetCore.Mvc.Abstraction.dll). I want to decompile it and see the source code.
The dll is added to my project>Dependencies>Nuget.
However, I am not sure where exactly the dll in in my system.
Is there a quick way to just launch the added dll in ILSypy and see the codes or at least the object inheritance tree?
Thanks.
ASP.NET Core is open source, so as Hans wrote as a comment to your question, you can look directly at the source, you don't need to decompile.
But for future reference, NuGet dlls are extracted to one of two places. Older projects still using packages.config, the dlls are typically extracted to a folder named packages as a sub-folder of where the .sln file is.
Packages using PackageReference, the packages are extracted to your account's global packages folder, which by default is %userprofile%\.nuget\packages on Windows and ~/.nuget/packages on Linux and Mac. You can also look at your project's obj\project.assets.json file to find the paths to everything referenced.
All paths can be modified with nuget.config settings (or even msbuild properties for projects using PackageReference). But if this is the case, either you, or your team mate would probably know, so the default locations for the folders I listed above should be correct.
I have multiple projects in the same folder, each of them creates a microservice. Each has a separate build and release pipeline. Currently each project is configured so to trigger when code is committed in its own sub folder. I am currently in the process of adding some common code which is used in some of the projects. I would like for a microservice to build and deploy if it uses a library that is being changes.
What is the best way to achieve this?
Ideally, I imagine something like this:
Build task which triggers on root directory -> Use MsBuild to determine if a project needs to build, by checking its dependencies -> Build/Abort.
Is this possible?
If you want to share code in source form and you are using .NET Framework projects, the best (but not optimal) approach that I found is to have the projects in the same folder and put the shared code in a subfolder that you include in both projects. To put shared code in a folder outside the root folder of a project is even worse.
The best approach (IMO) is to share code in compiled (Dll) form (rather than in source form): you can create a DLL with the shared code, package it in a NuGet package, and publish the NuGet package in some internal NuGet repository (for example, you can use the Artifacts feature of Azure DevOps as NuGet repository for your organization). The projects that require the shared code do it through NuGet references. The advantages is that the shared code in Dll/NuGet form can be versioned (not all projects must be updated at the same time for incompatible changes), it can use its own CI pipeline with unit tests, it can use its CD pipeline to publish to the Artifacts repository, etc.
I switched from the former approach to the latter. Much cleaner IMO.
I've been fiddling with the TFS2015 task based build system for a few days now. The problem I keep on running into is the following:
I am trying to use nuget packages for my external references in my projects. These exernal references are actually not 3rd party libraries but simply other (shared) libraries of our company. I'm able to restore the packages in a task, but I can't figure out how i can make the "Visual studio Build" understand where to find the restored packages. It uses the hintpath in the project file to determine the location of the external libraries to include. However, these paths (which are used locally for development) don't match the paths used on the build server. I can add a referencepath to the msbuild parameters, but this path isn't searched recursively, and the nuget package restore restores packages including the entire folder structure of the package.
My question is. Is there a proper way to make the "Visual Studio build" step understand the location of my packages without changing the hintpath in the project file. If not, what is the normal way to go here. Should I move away from nuget altogether because our references are not actually 3rd party libraries, and if so, what is the alternative way of resolving the references (without adding the binaries to source control)
My question seems to be related to Storing nuget packages in alternate location on build server, however he seems to have fixed it using a copy to the location that is specified in the hintpath of the references, which is not an option for me. It seems to me there should be an easy way I'm not seeing to be able to point msbuild to the correct location for the libraries.
After the task restoring packages, you can add task "Copy Files" to copy the packages to the location "..\packages\lib\lib.dll"
When I looked at the tutorials of MVC6, I get confused the usage of project.json. By my understanding this file is used to specify the project dependencies.
Prior to ASP.NET 5, we use nuget to manage the dependencies. But from some limited MVC6 samples I have seen I don't see people mention package.config any more.
Please help me to understand:
Do we still use nuget to upgrade all depending components?
Or we have to modify the project.json manually?
By my understanding [project.json] is used to specify the project dependencies.
Yes. One of the main functions of project.json is to manage server-side dependencies. (It also specifies other project specific settings.) See the project.json file for more info.
Prior to ASP.NET 5, we use nuget to manage the dependencies.
Yes again. And, ASP.NET 5 still uses NuGet to manage dependencies. The configuration differs though. Instead of using packages.config we use project.json > dependencies to list our project's NuGet packages (and other local dependencies.)
...from some limited MVC6 samples I have seen I don't see people mention package.config any more.
Yes again. Instead of package.config, ASP.NET 5 lists all dependencies, including NuGet packages, within project.json > dependencies. These dependencies can be NuGet packages, local assemblies, or local projects.
To expand on this, in Visual Studio, the References folder is a reflection of our project.json > dependencies section. What we add to the one will appear in the other. See server-side dependency management.
In some ways, you can think of the References folder as a GUI view of project.json > dependencies. For instance, here is a dependencies section from one of my projects alongside the References folder.
Note the one-to-one correspondence between what is listed in project.json and in the References folder (ignore the fx/ stuff that isn't in dependencies).
Note the the icons beside the items that References lists. These indicate whether the reference is a project, NuGet package (blue), or assembly.
Do we still use nuget to upgrade all depending components?
Yes. We just use it differently. If we add a NuGet package to our project.json - either manually or via the GUI's package manager - then we will restore/update those using the NuGet feed.
Or [do] we have to modify the project.json manually?
No. You can modify project.json manually but there are two mains ways to add NuGet packages. Which you use is personal preference.
Edit the project.json file manually.
Use the Visual Studio GUI.
Use the Visual Studio Code GUI.
Importantly, what you do to via the GUI will be reflected in the project.json file, and what you do to project.json > dependencies will be reflected in the GUI.
Do we still use nuget to upgrade all depending components?
The short answer is yes.
We have to modify the project.json manually?
You could also do that.
You can really do anything you want:
You could use the nuget package manager UI.
You could use nuget CLI through the Package Manager Console.
Or, you could even add, remove, change dependencies by modifying the project.json which has a really nice auto-complete like in the Package Manager Console.
The only difference now is that there isn't any mention of the installed packages in the project file (previously *.csproj), so yo don't have to add the references manually like when we had the packages.config.
Do we still use nuget to upgrade all depending components
No, you can just add them by your hand with the versions. Most of the IDEs and code editors has support for nuget dependency auto-complete inside project.json file.
More info on project.json file: https://github.com/aspnet/Home/wiki/Project.json-file (could be a little outdated).
More info on DNX dependencies: http://docs.asp.net/en/latest/dnx/overview.html?highlight=project#dependencies
I downloaded two DLLs (libgit2sharp.dll and git2.dll) from this site.
After that I successfully added Libgit2sharp.dll by add reference in my .NET Windows application. Now when I add git2.dll by add reference in my .NET Windows Application, it gives an error:
a reference to 'C:\User\nitesh\git2.dll' could not be added please make sure that the file is accessible and that it is a valid assembly or COM component
Can anyone please help me understand the problem?
I downloaded two DLLs (libgit2sharp.dll and git2.dll) from this site.
First off, this is not a distribution channel that the libgit2/libgit2sharp team has anything to do with.
Install as a NuGet package:
Official releases are available as a NuGet package if you prefer to download pre-built sources. See this post which explains how to install the NuGet Package Manager in Visual Studio.
This is the easiest way to make LibGit2Sharp available to your project.
Build from the source code:
You can download the source code and build the C# code into LibGit2Sharp.dll from https://github.com/libgit2/libgit2sharp, which includes the pre-built version of git2.dll which works for the particular version of the C# code.
Easiest way to build the assembly is by launching the build.libgit2sharp.cmd. This will create a Build folder into which you'll find the LibGit2Sharp.dll and a NativeBinaries folder with the native binaries.
Now when I add git2.dll by add reference in my .NET Windows Application, it gives an error
As for the error message, it sounds like you're trying to add the git2.dll to the project as though it were a CLR/.NET assembly. It is however built from C and isn't something VS is going to do anything useful with. You do not need to add it to your project.
It does need to be available for libgit2sharp to load. The following graph depicts the folder hierarchy that libgit2sharp expects
NativeBinaries+
|___amd64+
|___git2-{shortsha}.dll
|___git2-{shortsha}.pdb
|_____x86+
|___git2-{shortsha}.dll
|___git2-{shortsha}.pdb
Note: This folder structure will be dynamically created in your project output folder if you installed LibGit2Sharp as a NuGet package. However, if you built the project from the source code, you'll have to copy this folder structure as part of your project build process yourself.