I am taking the plunge and am converting a (Profile 7) PCL to the new .NET Standard format. I mostly have everything working. (This is a great article -- but perhaps a little dated -- if you are interested).
My only remaining issue is that it doesn't appear that the .targets file for one of my dependencies (PostSharp) is executing during the build of my project. I have been looking all over to see how to include/execute a MSBuild .targets file.
The closest I could find is some sort of spec listing here:
https://github.com/NuGet/Home/wiki/%5BSpec%5D-Managing-dependency-package-assets
However, that doesn't appear to be available when I break out my dependency node. The only available options are "build" and "default":
So, is it possible to include/execute an MSBuild .targets file manually in a project.json file?
OK this was due (as to most of my problems!) to poor understanding of the new paradigm as I learn it. It turns out you can reference .NET Standard libraries from a PCL that is running project.json. The trick is to NOT upgrade the PCL to .NET Standard, and simply update it to use project.json (and NuGet 3.0), using the same profile that was used pre-project.json.
From there you can reference any .NET Standard library and/or any traditional/legacy PCL from the new project.json-PCL. Kind of cool. :)
Related
I want to package some tools as a nuget and am using the Microsoft.Build.NoTargets project SDK format to achieve the same.
As mentioned in the docs, NoTargets is used when the project file does not compile any assembly. However, it needs a TargetFramework property to be set.
msbuild fails with NETSDK1013 if I don't specify some TargetFramework property.
Why does msbuild mandate that TargetFramework be specified for the NoTargets SDK csproj?
Currently this is required for it to load in VS: VS checks if the project contains TargetFramework or TargetFrameworks in the xml to load sdk-based projects in the "new" project system (the thing that powers the IDE integration of the project). Otherwise it would use the legacy system that would not understand the features the SDK uses and either not load or give you a bad experience.
The MSBuild errors could be fixed in the SDK by defaulting the property but that will still fail IDE integrations.
Also note that the SDK imports other SDKs that are meant for .NET projects (language-independent over F#/C#/VB) and so you should get features like NuGet restore or packing working without much friction when a TargetFramework is set (even if it could be defaulted to whatever the SDK is basdded on in the NoTargets itself as mentioned)
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 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).
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
Please bear with me on this, since I am a Java developer just dipping a toe into the ASP.Net world
I started coding in an existing C# VS2012 codebase. It uses nuget and Newtonsoft is mentioned in the packages.config
When I right-click on Controllers > Add a new controller, I get the following error.
Could not load file or assembly 'nunit.framework, Version=2.2.4.0, Culture=neutral, PublicKeyToken=...' or one of its dependencies.
The system cannot find the file specified.
Now looking around in Google, it seems the GAC is missing an NUnit assembly. Not sure what I should do about that. Should I get NUnit? Why is it looking for a certain version of nunit (& that too a very old one)?
Any help for me to resolve this problem will be highly appreciated!
When you click "Add new Controller' Visual Studio will try to complete the parse/build to populate a number of values in the window that it is supposed to show you (with the available Models and available Views). It looks like at least one of your projects is missing a dependency (probably your Unit Test project).
NUnit 2.2.4.0 is indeed a pretty old version, it doesn't even exist on NuGet yet (which would have been an easy fix). It makes sense that NUnit is not installed in the GAC, since you normally don't put everything in the GAC just because it seems to be possible. If you're willing to upgrade to the latest NUnit version, the easiest way is to add the NUnit NuGet package to your project through the Package Manager.
I would assume that when you'd open the project file for the project that is generating this warning in Notepad, you'd see a <hintpath> tag as a sibling of the NUnit Reference (it may not be there) which points to the folder where it is telling Visual Studio to look for NUnit.
I suggest you install the NUnit version your project is looking for from here and then update the reference in your project to point to the correct location. That should fix the issue.
As for your remark on the specific version, .NET Assemblies are compiled with a specific version number (usually set in the AssemblyInfo.cs) a reference in a project file can be to a specific version or to any assembly with that name (highlight the reference in the Solution Explorer and check the properties window (ctrl+w,p or alt+enter). You'll see a property "Specific Version" which in your case is set to "true" which caused Visual Studio to store the assembly version in the project file.
Add the code files into a workable solution project.
It is workable for me.
Or, try to create a new Nunit test project with the codes
I also try the following method, but not working for me
Install Nunit, adapter, SDK from the Nuget package
Clean-Rebuild