Today I had a problem with some routing in my ASP.NET MVC 3 application (with Visual Studio 2010).
So I thought I install the ASP.NET RouteDebugger and fix my route problem.
After I get the package through NuGet my project doesn't build anymore:
referenced assembly ' RouteDebug' does not have a strong name
I could download the source of the RouteDebugger and build (and strongly sign) it myself, but that's not the purpose of NuGet isnt' it ;)
Anyone else had this problem and maybe fixed it?
Well, the problem is not really related to NuGet. You cannot reference unsigned assembly from a signed assembly. And because the RouteDebug.dll as contained in the NuGet package is not strongly signed you won't be able to use it if your application is strongly signed. So you basically have two possibilities to choose from:
Download the source code of RouteDebug and compile it yourself by signing it with a strong key
Remove the strong key signature from your hosting application.
It is possible to sign an already compiled assembly without having to use the source code. This is explained here: http://www.geekzilla.co.uk/ViewCE64BEF3-51A6-4F1C-90C9-6A76B015C9FB.htm. In short, you need to use ildasm to get the IL for the assembly, then use ilasm to regenerate the dll, this time signed:
ildasm SomeAssembly.dll /out:SomeAssembly.il
ren SomeAssembly.dll SomeAssembly.dll.orig (for backup purposes)
ilasm SomeAssembly.il /dll /key= keyPair.snk
But yes, using unsigned NuGet packages in a project with signed assemblies is a pain in the ass...
This is a recognized shortcoming of nuget, as discussed here.
This is a common problem as many nuget packages are not strong named. It is possible to work around this by dynamically giving any included nuget packages a strong name at build time. Include nuget add package "Brutal.Dev.StrongNameSigner" to your project.
Then in your .csproj file, add a reference thus:
<Target Name="BeforeBuild">
<Exec ContinueOnError="false"
Command=""..\packages\Brutal.Dev.StrongNameSigner.1.8.0\tools\StrongNameSigner.Console.exe" -in "..\packages"" />
</Target>
Then at compile time, your unsigned nuget references will get a signature generated, and your assembly refernces will be updated to match the newly generated signature.
nuget: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/
project: https://github.com/brutaldev/StrongNameSigner
Add StrongNamer to your nuget dependency list and it will automatically sign any unsigned references without having to add any additional build steps yourself.
https://www.nuget.org/packages/StrongNamer/
Related
Assuming I have packaged a .net application e.g. MyConsoleApp.nupkg and have it available in a source, how would I go about "installing" this to a folder, such that I can run it from this folder:
my-folder/MyConsoleApp.dll
my-folder/Newtonsoft.Json.dll
....Other references....
I have tried nuget install with packagesDirectory option, but this gives the familiar output in the packages folder e.g:
myconsoleapp/1.0.0/lib/netcoreapp3.1/MyConsoleApp.dll
newtonsoft.json/11.0.1/lib/netstandard2.0/Newtonsoft.Json.dll
newtonsoft.json/11.0.1/lib/netstandard1.3/Newtonsoft.Json.dll
newtonsoft.json/11.0.1/lib/net20/Newtonsoft.Json.dll
....Other references....
I imagine there is a msbuild target which copies the correct content out of the packages directory to a build directory - is there an easy way to use this?
I have tried using dotnet restore/build with variations of a .proj file using PackageReference which make no reference to a specific build target, but these have not worked:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="MyConsoleApp" Version="*" />
</ItemGroup>
<Project>
I don't want to make a MyDummy.csproj which references my console app (or asp.net core app) to achieve this because it doesn't seem very clean, and I'm worried about getting the SDK and <PropertyGroup> stuff compatibly correct.
I understand this may not fall under best practices, but I would like to see if it can be done in any case.
Background
I want to deploy a mesh of c# core libraries, applications and plugins such that they all use the exact same versions.
The libraries (core application framework) are referenced by the applications (web apis, background service workers) and by the plugins (dotnet-script with nuget references to the libraries). The plugins are in turn invoked by the libraries.
The plugins must reference the same library assemblies as loaded by the applications, yet are resolved as NuGet references at runtime, which avoids a long list of guessed references to System.Etc.Dll in the scripts and related runtime failures.
Installing the applications via nuget packages leads to an interesting way to get a single source of truth for all - the nuget source.
I've seen how dotnet-script manages to do it:
https://github.com/filipw/dotnet-script/blob/master/src/Dotnet.Script.DependencyModel/ProjectSystem/csproj.template
During the msbuild of a project that has packagereferences, you are able to get access to the list of references. This is similar to doing a full build of a dummy project, but looks likely the only way to do this as of now - nobody seems to want to answer so I'll leave this here!
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
Everything was rolling along smoothly until a few days ago when UWP all of a sudden stopped building after pulling a new version from VSTS (git) with the errors:
Cannot resolve Assembly or Windows Metadata file 'Type universe cannot resolve assembly: X.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.'
Could not copy the file "obj\x86\Debug\MainPage.xbf" because it was not found.
Could not copy the file "obj\x86\Debug\App.xbf" because it was not found.
Could not copy the file "obj\x86\Debug\X.Mobile.UWP.xr.xml" because it was not found.
I have a solution structure of the following:
X.Core (.NET Standard class library)
X.Mobile (.NET Standard PCL)
X.Mobile.UWP (UWP specific project)
UWP references Mobile, and Mobile references Core (Core is also referenced by a web API project).
The commit that I pulled from source control did not have any changes to the X.Mobile.UWP .csproj file.
Things I have tried:
The obligatory clean and rebuild.
Delete all obj and bin folders for the entire solution.
Remove and re-add all references in the .UWP project.
Upgrade Xamarin.Forms to the latest stable (3.1.0.637273).
Remove and re-add X.Core reference in the X.Mobile project.
Delete C:\Users\%username%.nuget folder.
Update Microsoft.NETCore.UniversalWindowsPlatform to the latest stable (6.1.5).
Change the target version to all available versions - we've been running on build 16299 for several months.
And I've been beating my head against this problem on and off for days now. Android and iOS projects build just fine, which is ironic considering UWP has been our most stable platform. Anyone have any insight?
EDIT:
After adding a reference to X.Core directly to the X.Mobile.UWP project, I can compile. This shouldn't be the answer though since UWP never directly references Core.
I found the solution.
I had the very same problem because I had added a new (.Net Standard 2.0 Class Library) project into my Xamarin.Forms solution.
In short, initially my solution included the following projects:
BackgroundTaskTest (which have all my Views and ViewModels)
BackgroundTaskTest.Android
BackgroundTaskTest.iOS
BackgroundTaskTest.UWP
Suddenly I decided to add a class library named "BackgroundTaskTest.Common" in the same solution folder:
BackgroundTaskTest.Common (new one)
BackgroundTaskTest (which have all my Views and ViewModels)
BackgroundTaskTest.Android
BackgroundTaskTest.iOS
BackgroundTaskTest.UWP
The Android was working fine with it but the UWP project didn't like that new neighbor (which in your case is named "X.Core"). So I moved my classes from that new project to the "BackgroundTaskTest" again and deleted "BackgroundTaskTest.Common" from my solution with all the references and it has started working.
To finalize and make it short, please compare your X.Mobile.csproj file with X.Mobile.Core.csproj file. you will find the issue in the differences. Plus try to check all your dependencies to the X.Core project to make sure they are the same.
I installed NuGet package "NETStandard.Library" and added a reference to all my .Net Standard libraries to my UWP project. This solved the problem for me!
I'm nearly done with my app. I'm using Xamarin.Forms (PCL project for the shared code). Is there any benefit of switching PCL into .Net Strandard? I have read some articles, but still not 100% sure whether are there any benefits of upgrading, e.g. security, performance or is't more like richer API mainly? Thanks for any thoughts.
There is no direct improvement in security or performance, but in time .NET Standard will replace PCLs. The PCL is not as cross-platform as Standard, so to make it truly cross-platform the switch to Standard is the smart thing to do.
Also, a lot of NuGet packages are already switching to support Standard, and you will not receive any upgrades for that code in your PCL library. So coming back to the security and performance part; if a bug is found in a NuGet package, you will not receive the update containing a fix because you're still on the 'older' PCL technology. This is a bit of a stretch, but if you want to be future-proof, the switch to .NET Standard is mandatory.
Right now we're in a bit of a pickle. You cannot reference a Standard from a PCL and vice versa (not 100% sure on all scenario's but I think you can't). So, right now you have to carefully check if all NuGets you are using, have a .NET Standard version already. If not, you're stuck on a PCL if you can't do it without the NuGet. The creator of the NuGet could supply a PCL and .NET Standard version in one NuGet, so then you can transition from one to the other. But see if that is true for all plugins you are using.
There is actually a good post on this by Adam Pedley here.
Actually, you can refer a PCL from .netstandard and vice versa, but it depends on netstandard version and PCL profile. Refer to this table to find out what is possible in your case.
To move from PCL to netstandard:
1. Replace *.csproj content with this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.1</TargetFramework>
<PackageTargetFallback>$(PackageTargetFallback);portable45-net45+win81+wpa8</PackageTargetFallback>
<Copyright>Copyright © 2018</Copyright>
</PropertyGroup>
<ItemGroup>
<Folder Include="Properties\" />
</ItemGroup>
</Project>
2. You can add PackageTargetFallback tag if you want add references to PCL libraries. Also you can edit the value you need. In the example above I use "portable45-net45+win81+wpa8" to add PCL(Profile111) in the netstandard1.1 library.
3. Use the netstandard version you need. Copy info from "AssemblyInfo.cs" to the project settings (Properties->Package) and remove it as you don't need it anymore.
4. Manually install back nuget packages from "packages.config" file and scan old *.csproj file for references to you projects. Add them as well. Then you can remove "packages.config" file as well.
I tried it on VS2017 15.7.5. I found that it's better to use netstandard1.1 and profile111 if you develop for Xamarin.Forms (Android + iOS). In this case, you can still use old .NETPortable nuget packages (even though they don't support netstandard yet).
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.