is there a way to avoid nuget package references to ease development on a developers machine?
we are currently about to move some of our projects in our "shared" solution to the new csproj file structure (using <Project Sdk="Microsoft.NET.Sdk">) and using <TargetFramework>netstandard2.0</TargetFramework>.
By doing so we had to include <PackageReference Include="System.Text.Encodings.Web" Version="4.7.0" /> and changing some of our code in project "S" of our shared solution.
Within another solution backend we are having multiple projects. Some of them are referencing the assembly of project S by using assembly reference to S.dll like so:
<Reference Include="ournamespace.S">
<HintPath>..\..\artifacts\Shared\ournamespace.S\ournamespace.S.dll</HintPath>
</Reference>
When we build every works fine. However when running our web application W from backend solution we get this exception:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Encodings.Web, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Before we have migrated our shared projects to the "new SDK" project file format, before using .netstandard2.0 (we were using .net framework 4.7.2) and before we switched the package reference to System.Text.Encodings.Web (we were using <PackageReference Include="AntiXSS" Version="4.3.0" />) we have not received any error.
The only way i can think of is that we would need to switch from assembly reference for S.dll to use nuget - to get S dependencies.
However using nuget packages for our shared solutions projects and developing in backend projects would become a nightmare as we would need to create a new nuget package (and publishing it) on every change of S and would need to increase the version number in the package references in backend projects all the time. Also this would become very impractical as our developers are using various git feature branches too (thinking about versioning conflicts; having to release unfinished packages and maybe using version suffix "alpha_"+{branchName} to distinct the branch that this version is coming from).
How to develop on localhost? Is there a way to avoid nuget (but getting its dependencies resolved correctly!)?
I was already reading about having assembly references for local development while using nuget package references for CI builds by using conditionals in the csproj file (however this is also not working very well with VS2017; also this would not resolve our problem with the dependency problem written above on localhost)
What other possibilities are there? Is there a best way on how to handle this?
Thanks in advance!
P.S. I dont want to include S's dependencies to every project that references S by using package references there as well. This would not be a solution and becomes more cumbersome when S might get new dependencies for whatever reason.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
solved my problems (see How to get .NET Core projects to copy NuGet references to build output? for details)
I am having difficulty getting rid of the build warning:
warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved
specifically in .NET core projects.
In a full .NET framework project I would add some binding redirects so I googled around that issue and found this answer suggesting adding the following to the .csproj file:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
I have done this but to no avail - I still get the build warnings. Anything else I can do?
I had a look at your project and the problem seems to be a conflict with the versions that Rssdp was built against and the assembly version that the referenced System.Net.Http version (4.3.0) provides as compile-time reference.
This can be fixed by updating System.Net.Http to 4.3.2.
<PackageReference Include="System.Net.Http" Version="4.3.2"/>
Run Update-Package via Package Manager Console, this will fix MSB3277, what it does it reinstall all the packages with highest version possible.
More info on official docs https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages
I had the same issue. Got several warnings on one of the projects. I updated all packages from the solution level and warnings went away.
I used the Visual Studios for Mac to update the package.
Right click the solution, then Update Nuget Packages.
Does any of you dependencies use <PrivateAssets>?
If project A has a private reference, and both the private reference and another reference requires some package X, but the private one requires a higher version of package X, then the assembly for project A will also require the higher version of package X.
However you end up with a situation where any other project, e.g. project B, that references project A will only see the lower version of package X as a dependency - hence select the lower version of the assembly of package X to be copied to the output directory. The good news is that this DLL-HELL is detected at build time, where it sees that assembly projectA.dll requires a different projectX.dll than the one already designated as primary, and thus it logs some very unhelpful output about packageX being required by itself, which makes no sense... and gives up the build.
I am currently trying to create with Visual Studio a C# application working with SQLite. I installed SQLite for my program with NuGet and three references appeared in the Solution Explorer (System.Data.SQLite, System.Data.SQLite.EF6, System.Data.SQLite.Linq).
When I execute my app in VS, everything works fine. However, whenever I publish it (with ClickOnce) and try to run the app, it crashes with the following error :
System.DllNotFoundException : Unable to load DLL 'SQLite.Interop.dll' : the specified module cannot be found (Exception from HRESULT : 0x8007007E)
After some research, I found this dll in the Debug folder and copied it in the folder where the ".exe" version of my program is created (after publishing and executing "setup.exe"). This way, the app runs well.
But I'm not really satisfied with this solution, since it seems really dirty. I don't want future users to have to do this manually when they install my app !
Therefore, my question is : What can I do to make sure that this dll is installed together with my program ?
Note : I tried the first answer of this post :
unable to load dll sqlite interop dll WPF
But I didn't seem to work for me.
I also encountered the similar issue in my environment of Visual Studio 2017 and NET Framework 4.5, the circumstance is:
I am developing an Outlook Add Ins using ClickOnce to publish it and SQLite as the database. After having installed the SQLite library into the project from NuGet, it works perfectly in the local environment but pops up the exception error message "Unable to load DLL 'SQLite.Interop.dll'" on the client machine.
I compared the two environments and found the DLL file 'SQLite.Interop.dll' had not been published to the client machine that we can see in the following graphic.
I searched 'SQLite.Interop.dll' in local environment and found it is saved in the following folder "{project}\packages\System.Data.SQLite.Core.1.0.105.2\build\" for the specific .Net FrameWork
So, my solution is adding these two DLL libraries into the project, then they can be published to the client machine using the ClickOnce.
(Notice: The selected DLL version should be as same as the NET Framework version in your environment.)
See Using Native Library Pre-Loading at https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
You likely need to include the x86 and x64 folders under the the other SQLite DLL.
Edit: I've added the relevant info below in case the above link ever dies/changes.
If the development and customer machines may have different processor
architectures, more than one binary package may be required. For this
situation, using the native library pre-loading feature is highly
recommended. It is available as of version 1.0.80.0 and enabled by
default. In order to take advantage of this feature, the separate
managed and interop assemblies must be used with XCOPY deployment
(i.e. this feature is not supported by the mixed-mode assembly, nor
when the assembly is deployed to the global assembly cache), resulting
in an application deployment that looks something like this:
bin\App.exe (optional, managed-only application executable
assembly)
bin\App.dll (optional, managed-only application library
assembly)
bin\System.Data.SQLite.dll (required, managed-only core
assembly)
bin\System.Data.SQLite.Linq.dll (optional, managed-only
LINQ assembly)
bin\System.Data.SQLite.EF6.dll (optional,
managed-only EF6 assembly)
bin\x86\SQLite.Interop.dll (required,
x86 native interop assembly)
bin\x64\SQLite.Interop.dll (required,
x64 native interop assembly)
The string "bin" above represents the directory where the application
binaries are to be deployed on the target machine. With the native
library pre-loading feature enabled and the application deployment
shown above, the System.Data.SQLite managed-only assembly will attempt
to automatically detect the processor architecture of the current
process and pre-load the appropriate native library.
Please use the answer to the duplicate issue: https://stackoverflow.com/a/60176344/3634867
Don't store the dll yourself and copy it to /bin manually, it will lost control to the version updating and dependency.
TL;DR;
for old csproj file:
<PropertyGroup>
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
<CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
<CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
<CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
</PropertyGroup>
for new csporj file: (i.e. projects beginning with <Project Sdk="Microsoft.NET.Sdk.*">)
<PackageReference Include="System.Data.SQLite.Core" Version="1.0.110" PrivateAssets="none"/>
By default the dll sqlite.interop.dll does not come with NuGet installation of SQLite. To solve this you need to add both the dlls, x86 and x64.
At the SQLite website download the pack containing necessary dlls. Install them in client or copy these dlls to your Project before distributing.
Upgrading the System.Data.SQLite.Core Nuget package to version 1.0.109.2 fixed the error for me.
If it is an installable file. i.e, if u are creating setup file, then you have to add the dll manually to the primary output file.
Go to properties of the setup project and in configuration settings, select pre-requisites SQLLite, select(Checkbox) install it from the project location.
See if this solves your issue.
"Note : I tried the first answer of this post : unable to load dll sqlite interop dll WPF But I didn't seem to work for me."
I tried that, too, and finally got it working. However, important is:
Insert the sqlite.interop.dll as an existing item to the root of the project you are going to build.
In the properties of that file, make sure its build processing is 'content' (not embedded resource as suggested) and, of course, copied to the output directory always.
Hope that helps to beat that annoying bug.
The System.Data.SQLite nuget package includes a Build folder with a targets file that will copy these interop dlls. To solve this, we had to tell the project we were packaging into our own nuget, to NOT exclude this build target/folder.
Our project (the one we package and then use elsewhere) needed to have PrivateAssets="None" or PrivateAssets="Analyzers" if you want to make sure not to include Analyzers.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<GeneratePackageOnBuild>True</GeneratePackageOnBuild>
<RootNamespace>MyNamespace</RootNamespace>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ServiceStack.OrmLite.Sqlite.Core" Version="5.6.0" />
<PackageReference Include="System.Data.SQLite.Core" Version="1.0.111" PrivateAssets="Analyzers" />
</ItemGroup>
</Project>
SQlite.Interop is not referenceable, you have to:
In your VS project Add Existing File: Sqlite.Interop.dll actual
location is .\bin\Debug\x86 or \bin\Debug\x64
Select properties and set Compilation Action in "Content" and copy
to the output directory = "Always Copy"
Rebuild
One alternative solution might be to replace the xcopy post build by using the System.Data.SQLite.Core.targets script file from the System.Data.SQLite.Core package for doing that.
Here my working csproj file:
When trying to add references to a VSIX, it normally pulls it from the references in the .csproj. However, if the references are not in the .csproj, because they now are in a project.json file, then they don't get pulled to the vsix. The solution then may compile, but then the extension fails with "file not found" errors when installed into Visual Studio (since the assemblies where not copied to the VSIX).
I tried with the section of the manifest like so:
<Asset Type="Microsoft.VisualStudio.Assembly" d:Source="Project" d:ProjectName="*PROJECTNAME*" Path="|*ASSEMBLYNAME*|" AssemblyName="|*ASSEMBLYNAME*;AssemblyName|" />
But it does not work, as it does not recognize the package references.
After some research I saw a similar issue with a PCL, however, without an answer and not the same type of problem: MEF With Portable Class library using Microsoft Composition MEF2 throws file not found exception
In the same note, this seems like an acceptable workaround: VSIX with Project Templates and NuGet Packages however, as far as I understood, it implies using the package during the installation. Besides that, it doesn't work for our case as they need to specify the package version and we are using project.json so we can use floating versions (ie: 2.0.*)
Is there a way to reference this project.json references that we are missing? Maybe a workaround? The solutions I have found seem to all require to "paste" de DLL somewhere, which for floating versions is not that convenient.
Thanks in advance for any help or input.
Edit/Update: Since VSIX automatically pushes any assembly referenced in the CSPROJ (and not the project itself), trying to get the DLLs at a project level seems unlikely. After many tries, I think that a valid workaround would be to get the assemblies from the Output Folder. However, to my knowledge, VSIX does not have a way of doing this, or does it?
I'm not sure I'm understanding your question correctly, but if you're trying to install a Project Template via a VSIX and you want the project template to include all it's nuget packages when you use it you could do something like this.
Edit your Project Template's xproj file and add the following lines:
<ItemGroup>
<None Include="project.json"/>
<None Include="project.lock.json"/>
</ItemGroup>
Edit your Project Template's vstemplate file and add the following lines in the Project node:
<ProjectItem ReplaceParameters="true" TargetFileName="project.json">project.json</ProjectItem>
<ProjectItem ReplaceParameters="true" TargetFileName="project.lock.json">project.lock.json</ProjectItem>
That should be all you need to do. Now when you install the project template, then create a new project using that template it should include all the nuget packages that were in the project.json file.
I'm trying to compile my excel addin using C# 4.0, and started to get this problem when building my project in Visual Studio. It's important to tell you that I haven't had this problem before. What could cause this to happen?
When I had this problem I fixed it by turning off the 'Enable ClickOnce security settings'.
Menu: Project | 'Project name' Properties... | Security tab | 'Enable ClickOnce security settings' check box.
My guess is that you're not working with strongly named assemblies. I've had this error when two projects reference slightly different versions of the same assembly and a more dependent project references these projects. The resolution in my case was to remove the key and version information from the assembly name in the .csproj files (it didn't matter anyway), and then do a clean build.
Changes between the different assembly versions were compatible with the parts of the solution referring to them. If this is not the case with you, you might have to do some more work to resolve the issue.
NuGet
With NuGet it's easy to get into this situation if:
You install a package to one project in your solution.
A new version of that package is deployed to the package source.
You install it to another project in the same solution.
This results in two projects in your solution referencing different versions of that package's assemblies. If one of them references the other and is a ClickOnce app, you'll see this problem.
To fix this, issue the update-package [package name] command at the Nuget Package Manager Console to bring everything up to a level playing field, at which point the problem goes away.
You should manage NuGet packages at the solution level rather than at the project level unless there is a compelling reason not to. Solution level package management avoids the potential of multiple versions of dependencies. When using the management UI, if the Consolidated tab shows 1 or more packages have multiple versions, consider consolidating them to one.
See this answer.
Go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".
I've had this problem. It happened because i had many projects pointing to the same assembly but from different versions. I solve it selecting the same version to all projects in my solution.
If you have changed your assembly version or copied a different version of the managed library stated in the error you may also have previously compiled files referencing the wrong version. A 'Rebuild All' (or deleting you 'bin and 'obj' folders as mentioned in an earlier comment) should fix this case.
If you tried all the other answers in this question and you:
Have multiple projects in your solution
Have a project (Project A) that references another project (Project B), whose project references a NuGet package.
In Project A, you used Intellisense/ReSharper to bring in the reference to the NuGet package referenced in Project B (this can happen when a method in Project B returns a type provided by the NuGet package and that method is used in Project A)
updated the NuGet package via NuGet Package Manager (or CLI).
...you may have separate versions of the NuGet packages DLL in your projects' References, as the reference created by Intellisense/ReSharper will be a "normal" reference, and not a NuGet reference as expected, so the NuGet update process won't find or update it!
To fix this, remove the reference in Project A, then use NuGet to install it, and make sure the NuGet packages in all projects are the same version. (as explain in this answer)
Life Pro Tip:
This issue can come up whenever ReSharper/Intellisense suggests to add a reference to your project. It can be much more deeply convoluted than the example above, with multiple interweaving projects and dependencies making it hard to track down. If the reference being suggested by ReSharper/Intellisense is actually from a NuGet package, use NuGet to install it.
you need to sign the assembly with a key. Go in the project properties under the tab signing:
Adding my solution for this issue for anyone it might help.
I had a ClickOnce solution throwing this error. The app referenced a common "Libs" folder and contained a project reference to a Foo.dll. While none of the projects in the solution referenced the static copy of the Foo.dll in the "Libs" folder, some of the references in that folder did (ie: my solution had refs to Libs\Bar.dll which referenced Foo.dll.) Since the CO app pulled all the dependencies from Libs as well as their dependencies, both copies were going into the project. This was generating the error above.
I fixed the problem by moving my Libs\Foo.dll static version into a subfolder, Libs\Fix\Foo.dll. This change made the ClickOnce app use only the project version of the DLL and the error disappeared.
Deleting the DLL (where the error is occurred) and re-building the solution fixed my problem. Thanks
When this happened to me with the WindowsAPICodePack after I updated it, I just rebuilt the solution.
Build-->Rebuild Solution
I encountered this problem after migrating an Excel Addin from packages.config to PackageReference. Seems to be related to this issue.
The following works as a crude workaround if you're not using ClickOnce (it will omit all the dependency information from the .manifest file):
Unload project, edit .csproj
Find the section looking like this:
<!-- Include additional build rules for an Office application add-in. -->
<Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
Edit a renamed copy of the referenced .targets file (in my case, the file resolved to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets and I made a copy Microsoft.VisualStudio.Tools.Office_FIX.targets in the same folder - didn't check if it works from a different folder).
Find the GenerateApplicationManifest element and change its attribute Dependencies="#(DependenciesForGam)" to Dependencies="".
Change the section found in 2. to reference your edited .targets file instead.
This will have to be repeated whenever the version of the .targets file shipped with VS is updated (or you won't get the updates), but I'm hoping it will be fixed soon...
There were too many projects in my solution to go through and individually update so I fixed this by:
Right-clicking my solution and selecting 'Manage NuGet Packages for Solution...'
Going to the Updates tab
Finding the affected package and selecting Update
Clicked OK and this brought all instances of the package up to date
Unloading and reloading the problem project solved it for me.
I went to publish, application files, found the dll throwing the error changed it to 'Include' from 'Include (Auto)'. I can now publish.
Is your assembly properly signed?
To check this, press Alt+Enter on your project (or right click, then Properties). Go to "Signing". Verify that the check box "Sign the assembly" is checked and the strong name key file is selected and "Delay sign only" is unchecked.
Now Here is a different approach to the problem:
Right click on the project and select the 'Unload Project' option. You will notice you project becomes unavailable.
Right click on the unavailable project and select the 'Edit' option.
Scroll down to the ' < ItemGroup > ' tag that contains all the resource tags.
Now go to the reference that has been displayed on the error list, you will notice it it uses a single tag (i.e. < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).
Change that to look as follows:
.
<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
< Private > True < / Private >
< HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
Save your changes, Right click on the unavailable project again and click on the 'Reload Project' option, then build.
This is caused when you change the version of the .dll that is referenced. You need to delete all items, or the .dll in the target build folder.
I got the similar compiler error. Once I add the dependent project of the dll file to the solution, issue resolved.
If your main project using some library projects and have reference to them, you can cause this problem if your project reference to a assembly dll file instead to library project when you change something in your library project (ex: rename a class).
You can check all references to your main project by view in Object Browser window (menu View->Object Browser). A reference to a dll file always has a version number. Ex: TestLib [1.0.0.0]
Solution: delete the current reference of your main project to the library project and add reference to that library project again.
After trying most of the solutions here, I finally just added a reference to the project from the click once project, this changed it to Include (Auto) from Include and it finally worked.
What helped me was I went onto Package Manager Solution and looked at the installed package which was causing the issue. I saw that several projects were referencing the same package but different versions. I aligned them based on my needs and it worked.
I had this in a solution w/ 6 projects.
One of my projects was referring to the named assembly as a file reference. The others were all pointing to the project reference.
I usually get a different error in these cases.
My solution was to delete the named assembly anywhere it was referenced and add it back.
Once I worked through the project, ths problem disappeared.
Before doing this, I tried cleaning the solution as well as making sure none of the projects were signed.
hope it helps someone...
If its a mismatch of a dependencies dependencies, go to the NuGet package manager at the solution level and check the Update and Consolidate tabs, harmonise it all.
I recently hit this problem. In my case, I have NuGet packages on different assemblies. What I had was different versions of the same NuGet packages associated with my own assemblies.
My solution was to use the NuGet package manager upon the Solution, as opposed to the individual projects. This enables a "consolidation" option, where you can upgrade your NuGet packages across as many projects as you want - so they all reference the same version of the assembly.
When I did the consolidations, the build failure disappeared.
I also bump into kind of problem, all I just had to do is delete the .dll (can be found in reference) that causing the error and add it again.
Works like a charm.
Try with update-package -reinstall -ignoredependencies
Just go to Publish -> Application File -> And change the effected dll publish status from prerequisite to include!
This worked for me!
In my case, I upgraded the project to .net 4.7.2 but still built in old visual studio version (2015).
When i built the project in VS 2019, the build failure disappeared.