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
Related
I was looking at a solution that uses the https://github.com/microsoft/MSBuildSdks/tree/master/src/CentralPackageVersions.
Why can a single package version not be managed via the Directory.Build.props file?
A team mate #Oleg Jytnik explained this to me as such:
Directory.Build.props will add the packages to every project by default, but with the CPV, we can only specify the package version and then if we need the packages, we will just add them (w/o the version) to the individual projects.
One might ask if instead of the Global Package References provided in Packages.props, if we could use PackageReference in Directory.build.props with the specific version. The problem then might be that since the SDK runs after the Directory.build.props contents are appended, it might see PackageReference with a version and give an error as it expects PackageReference without versions.
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.
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 a single solution full of projects that are to be shared amongst my organization as general nuget packages. The solution is encompassed by one git repository and we have TeamCity running our builds for us, although we are not overly advanced in that we manually kick off the Teamcity builds when we are ready to generate/publish a new Nuget package for a given project in the solution, every project has its own TeamCity build configuration.
When built, the projects generate nuget packages via the .csproj <project/> tag: GeneratePackageOnBuild we also control the versioning via version tags that are populated through build properties from TeamCity. This works great. Where we run into problems is managing the project references/dependencies that the projects have on themselves. I can't seem to understand how to do this correctly. For example:
-- Solution
----- Project A v1.0.6
----- Project B v1.0.1
Project A (v1.0.6) has a dependency on Project B (v1.0.1). Let's say I change Project A (v1.0.7) and Project B (v1.0.2) at the same time. I can't have Project A reference the nuget package of Project B since it isn't built yet so I use Project References. However, that causes the nuget package of Package A (v1.0.7) to assume it has the same build number as Project B (v1.0.2) - which it doesn't. Thus, when someone consumes Project A they are told to look for a version of the dependency Project B that doesn't exist (v1.0.7 in the example). To resolve this, I added the following in Project A .csproj:
<ProjectReference Include="..\Company.ProjectB\Company.ProjectB.csproj" ExcludeAssets="All" />
However, now the consumer doesn't know of the Project B dependency (as it no longer shows up in the Nuget package dependency) and when they figure out they need it, they'll get a runtime error when using Project A stating that it is still looking for Project B v1.0.7 which obviously doesn't exist.
How does one intelligently handle project referencing when generating nuget packages without a nuspec? I'd like as little manual intervention as possible.
My one other solution is to use Nuget package references but that means Project B has to build and deploy before a developer can get to work on Project A.
By design, when you pack a project that has project references, those dependent projects are added as NuGet dependencies, with the minimum version being each project's current version at the time of pack. To understand why, imagine you made a breaking change to ProjectB, and fixed ProjectA to work with it. If you publish ProjectA, but with a NuGet dependency of an old version of ProjectB, then NuGet users of ProjectA will crash at runtime because the version of ProjectB they're using is incompatible. There's no way for NuGet to know this.
Therefore, if you want to increment ProjectA's version without incrementing the dependency version of ProjectB, make them in separate commits. Otherwise, publish new versions of both ProjectA and ProjectB at the same time.
I am working with .Net Core 1.0 (running under the .Net Framework 4.6.1, non-portable).
I need to include some DLLs that are from a locally-built GitHub project. When I build those projects, and then attempt to "Add Reference" to the resulting DLLs, I get a message saying I can't add them to a Core project directly.
After more research, I found a lot of information regarding "private" NuGet packages. However, those seem overly complex / overly engineered.
Is there any way I can do the following:
Without having to go through the headache of creating a private NuGet repository, can I just "add reference" to the built assemblies that are sitting in the bin folder of the NuGet projects I pulled?
I really don't want to have to build a local-only NuGet package. Mostly because I've already wasted too much time on this issue, and because I read this entire concept is about to be scrapped and turned into something else (sounds familiar by now)... such as the Roslyn-based build system on GitHub.
My current state:
Visual Studio Professional 2015
.Net Core 1.0.1
.Net Core 1.0.1 Tooling Preview 2
No, as for now you have to create a nuget package before and restore it via Nuget. You can use a simple folder as NuGet source, so if you put your compiled NuGet package in C:\packages, you can add this as a source to NuGet (while in the NuGet UI, click the settings Icon and add the folder as new source).
This may change with the next release of ASP.NET Core (1.1), as the .NET/ASP.NET Core team is working to move from *.xproj to *.csproj files.
One of the reasons why you need to use nuget is because it can contain multiple targets and project.json allows you to target multiple platforms (i.e. net452 and netcoreapp1.0).