System.Net.Http DLL not copied into bin folder - IdentityServer4.AccessTokenValidation - c#

I have a API project that uses .net core project using full .net 4.6.1 I was updating one of my nuget packages that uses Identity Server 4 and was making sure it was not conflicting with some of my old code so I deleted the bin folder content.
I rebuild the project and its now unable to inject my nuget package saying it can't find system.net.http 4.1.1.0. After many hours of slowly ruling things out it turns out that when the project rebuilt and put all its DLLs into the bin folder it did not copy the system.net.http DLL.
What is odd is when I create a new .net core API project using .net 4.6.1 and delete the bin folder and rebuild it does copy the system.net.http dll.
So my question is - how do I make sure the DLL is copied into the bin folder so this does not happen to someone else working on the project?
Update 2017-03-03 11:00
So I have found out what is breaking my project but I cant work out why / how to fix it.
1) If you create a blank .net core API project change it to use .net461 clean your bin folder and build it you will see the System.Net.Http DLL within the folder "bin\Debug\net461\win7-x64".
2) Now add IdentityServer4 AccessTokenValidation to the dependencies
"IdentityServer4.AccessTokenValidation": "1.0.5"
3) Clear your bin folder again
4) Build project and you will see the System.Net.Http DLL is missing.
The project should still work when you run it but I am using a nuget package that needs that missing DLL...

System.Net.Http should be a reference in the project that uses it. Get the reference's properties and set the property "Copy Local" to true.

If all of the options you did didn't work, please try restarting (close / open as "admin") your visual studio, then clean / rebuild. This has fixed my problem.

Related

.Net Plugin Architecture Not Working with Nuget

I have a .Net Core 3.1 console application that loads plugins. One of my plugins connects to Sqlite and so it has a Nuget dependency on Microsoft.Data.Sqlite. However, I'm getting a missing DLL exception from the console app when loading/running the plugin because the following path doesn't exist:
MyConsoleApp\bin\x86\Debug\netcoreapp3.1\runtimes\win-x86\native\e_sqlite3.dll
I also have an MsTest project which tests this Sqlite plugin project. It does not have the same problem. Apparently the runtimes folder and contents will automatically exist if a Visual Studio project (1) is some kind of executable and (2) has a pertinent Nuget or project reference.
Following those rules, two of my three Visual Studio projects do not have the runtimes folder:
The plugin has a Nuget dependency on Microsoft.Data.Sqlite, but does not have the runtimes folder because the plugin project is a DLL...not an executable.
The MsTest project which tests the Sqlite plugin does have the runtimes folder and contents because (1) it it is a type of executable and (2) it has a project reference to the plugin project (which in turn references the Nuget package).
The main console app is an executable, but (intentionally) doesn't have a project reference to the plugin. Thus it does not have the runtimes folder.
How do I solve this? As a hack I have simply copied the missing DLL into the output target directory for the console app.
Also, if I add a project reference from the console app to the plugin, this problem is solved. But, as stated, I don't want the console app to have project references to any plugins. Plugins should be discovered dynamically. I think fixing this may have something to do with creating a nuspec file. However, the documentation for nuspec files has no commentary about addressing this.
.Net Plugin Architecture Not Working with Nuget
Just as you said that, the lib plugins project which references Microsoft.Data.Sqlite does not have the runtime folder and when an exe project reference the lib plugins project, the runtimes folder will be copied into the the exe project's output folder.
Solution
1) Since you do not want to reference the lib plugins project for the console project, you can just do a copy task in msbuild from the MsTest project's runtimes folder.
Write this target in the xxx.csproj file of Net Core 3.1 console application:
<Target Name="Copy_Runtimes" AfterTargets="Build">
<ItemGroup>
<CopyItems Include="..\MsTest\bin\Debug\xxx\runtimes\**\*.*" />
</ItemGroup>
<Copy SourceFiles="#(CopyItems)" DestinationFolder="$(OutputPath)runtimes\%(RecursiveDir)%(Filename)%(Extension)')"></Copy>
</Target>
2) Besides, you can also install the nuget package called sqlite in the net core 3.1 console application, and this package only contains the runtimes folder and does not include other com dlls for using.
It is actually a pure service package for providing runtimes folder.
You can install this package in your console project directly and if you are not satisfied with this, you can only try solution 1 to solve the issue.

Nuget pack - Multiple errors with Microsoft tutorial

Following the Microsoft tutorial on NuGet .NET Framework here. I AM using VS 2019.
Everything goes fine until I get to NuGet pack. I get the following error:
'C:\Users\erics\source\repos\AppLogger.vs\AppLogger\v16\Server\sqlite3\db.lock' because it is being used by another process.
The .vs folder is created automatically in all my projects. If I close VS and delete the folder it is recreated. If I close the solution and then try pack again I get:
WARNING: NU5100: The assembly 'AppLogger\bin\Debug\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.
WARNING: NU5100: The assembly 'AppLogger\bin\Release\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.
WARNING: NU5100: The assembly 'AppLogger\obj\Debug\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.
WARNING: NU5100: The assembly 'AppLogger\obj\Release\AppLogger.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.
The NuGet docs were written before SDK style projects existed (before .NET Core was created), and mostly has not been updated since. Therefore the tutorials are very much out of date.
My 30 second tutorial for creating NuGet packages:
Create a "Class library (.NET Core)" project, even if you want to target the .NET Framework. You can also do this from the command line using dotnet new classlib. If you want to target the .NET Framework, right click the project in Solution Explorer, and select "edit project file" (or edit the csproj in your favourite text editor) and change <TargetFramework>netcoreapp2.2</TargetFramework> to <TargetFramework>net472</TargetFramework>, or whatever .NET Framework version you want (remove the dots so 4.7.2 is 472, 4.7 is 47, not 470). Finally, right click the project in Solution Explorer and select Pack, or run dotnet pack from the command line.
Packing SDK style projects (or traditional projects with the MSBuild pack targets) is much improved over using nuget.exe pack and nuspec files, so I strongly suggest using that instead. We (NuGet team) really need to find the time to update the docs.
I've checked the tutorial and reproduced same issue.
When VS is running with current project AppLogger opened, the .vs folder is used by it. (Create a new solution, and navigate to the SolutionDir, you can find the .vs is occupied by VS since we will fail to delete it when VS is running)
According to this error message, when using nuget pack command, it will also try to read some data from .vs folder. But the .vs has been occupied by VS and the nuget.exe can't access it. So the error occurs.
I would think it needs some additional note to the document like:
Note: To run the nuget pack xxx.nuspec successfully, you should close VS instance before it.
If I close the solution and then try pack again I get the warnings:
The warnings indicate that the assemblies you want to package should be copied to lib folder so that the project who loads this package can get the assembly. A simple way to reslove this error messgae is: Create a lib folder in the project folder and copy the xxx.dll into it. Then use the nuget pack command again.
Then the xxx.nupkg we created contains the assembly.
Create a new .net fx project, load the xxx.nupkg, now we can reference the AppLogger.dll correctly.
(Also, the warning would still displays:WARNING: The assembly 'lib\AppLoggerSampleMyTest.dll' is placed directly under 'lib' folder. It is recommended that assemblies be placed inside a framework-specific folder. Move it into a framework-specific folder.) But it's just a warning, which suggests to help make a better nuget package structure.
And according to your last comment, you're working in local dev development. Then you don't have to create nuget packages for this situation. I think class library project template itself is enough for your situation.
(If they are in same solution, right-click project=>add=>reference, if not in same solution, you can right-click solution=>add existing project to include the class library project)

Dependent DLLs of referenced ClassLibrary not added to BIN of application

There are so many questions posted about this issue. I believe i have read them all and still not having much luck. I have a VS2015 project where i can do all that i have described below without issue. Also note that the process i went through to move the applications and class libraries from 2015 to 2017 was to fully rebuild them in 2017. In any case, i created a new solution in 2017 with new application and class library to prove my issue.
I created a new library call ClassLibrary and a new asp.net web app called WebApplication.
In ClassLibrary i then added a nuget for testing (i have also tested this with a file reference to a 3rd party DLL). In this case i added the AjaxControlToolkit 18.1.0 for testing.
Then in WebApplication project i reference ClassLibrary
I would expect this simple solution and project referencing to copy the dependent DLLS of ClassLibrary to WebApplication project bin. It does not. Prior to moving to VS 2017 this would (and still does in VS 2015) copy the dependency DLL of ClassLibrary in WebApplication's BIN. In the VS2017 project i described above the AjaxControlToolkit is not copied to the BIN, i only see a ClassLibrary.dll but none of its dependencies.
I have tried to "use" the AjaxControlToolkit in the WebApplication project code as some of the posts suggest. This does not work as the assembly is not available in the project and i get build errors. I've modified the .csproj files in so many different ways based on suggestions i have found on Stack, nothing works.
Whats even more strange is that i see the DLL in the bin but not listed in the project References. Even though the DLL is in the bin i am unable to work with it.
What is going on? This is such a simple exercise of referencing and after spending two days on Google searching on this it seems crazy that so many have this issue. Why are these DLLs not flowing all the way to the parent application BIN???
Thanks
In my post i mentioned that these projects originally in VS2015 were then recreated in VS2017. This process converted the original Web Site projects to Web Application projects.
As mentioned here, in a Web Site project when a ClassLibrary is referenced as a project reference "Copies of dependent assemblies, XML document files, license files, resource files, and so on." (this includes installed Nugets in the ClassLibrary) are copied to the project BIN. This is not the case with Web Applications. See here for the differences. Installing the NuGet wherever it is needed is required, it will not be inherited from child references as it is with Web Site projects.

Nuget packages - HintPath after Deployment?

I have a C# class library project in VS 2017 that I'm trying to make work with Nuget packages in a somewhat strange release environment.
The project has a packages.config with standard Nuget packages such as EntityFramework 6.2.0 for example.
The project compiles fine, but the release environment is setup so that only the class library project DLL itself is deployed (no dependent DLLs).
The class library DLL needs to resolve the DLL references in a completely different directory such as C:\Dependencies, instead of the deployment location C:\ClassLibraries.
How can I resolve the dependencies that are in a completely different folder after release?
Edit: I already tried this HintPath Exists trick posted here, but it didn't work:
.csproj multiple hint paths for an assembly
Edit 2: I don't have access to the EXE that calls this DLL or the app.config associated with the EXE that calls this DLL.

Must the DLL be in the lib folder in a nuget package

I tried to download the latest version of this nuget:
JSON Web Token Handler For the Microsoft .Net Framework 4.5 3.0.1
but its not installing correctly in my project.
In my Visual Studio solution, I looked in the folder:
\packages\System.IdentityModel.Tokens.Jwt.3.0.1\
and the DLLs exist, but they are not within the lib folder. They are in the package's root.
When I try to install it in my VS project, it says its been installed, but no project references are added.
I think its broken. Can anyone confirm that a nuget must have a lib folder and the DLLs must be within the lib folder.
Yes, I duplicated the folder structure of the previous package (version 3.0.0) and got it working. I left two messages with the author a week ago.
We just pushed a new version out, 3.0.2, that fixes this issue. Please try to update the NuGet and let me know if the issue is resolved.

Categories

Resources