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)
So I've come across a similar issue twice now while working on my first project in C#. When trying to add either using System.Data; or using System.Timers;, I get the following error:
The type or namespace name 'x' doesn't exist in the namespace 'System' (are you missing an assembly reference?).
I have tried beginning a new project and running restore to see if I had accidentally removed something in the dependencies, but upon generating a new project I still receive the same error. I have tried to research the question and have seen answers referring to the 'solutions explorer', but as far as I can see there doesn't seem to be such a feature by this name in Visual Studio Code 1.8.
Can anyone point me in the right direction for how to get these working, perhaps by manually adding into the dependencies?
.csproj Project file
The following topic applies to .csproj project file and : .NET Core 1.x SDK, .NET Core 2.x SDK
Adds a package reference to a project file.
dotnet add package
Example
Add Newtonsoft.Json NuGet package to a project:
dotnet add package Newtonsoft.Json
.json Project file
The following topic applies to .json project file:
This guide walks you through the process of adding any assembly reference in Visual Studio Code. In this example, we are adding the assembly reference System.Data.SqlClient into .NET Core C# console application.
Note
At step #6, enter the assembly reference that you want.
Some assembly reference is applicable to .NET Framework and it will gives you error(s).
OleDb is not available in .NET Core, probably because it's not cross platform.
Prerequisites
Install Visual Studio Code
Install .NET Core SDK (Preview 2 version)
Install NuGet Package Manager from the Visual Studio Code Extension Marketplace
Install C# extension from Visual Studio Code Extension Marketplace
Steps
Launch Visual Studio Code
Open your project folder
Launch VS Code Command Palette by pressing F1 or Ctrl+Shift+P or Menu Bar > View > Command Palette
In Command Palette box, type nu
Click on NuGet Package Manager: Add Package
Enter package filter e.g. system.data (Enter your assembly reference here)
Press Enter
Click on System.Data.SqlClient
The following prompt pops up
Click on Restore
The following Output panel pops up
In the Explorer panel, click on project.json to open it
In the Editor panel, it shows the assembly reference added into project.json file
Assembly reference, System.Data.SqlClient used in Program.cs
Use the command dotnet add package to add a package reference to your project. For example: dotnet add package Newtonsoft.Json, which adds the package reference to the *.csproj project file:
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
and now you can run the command dotnet restore to restores the dependencies of your project.
Reference: dotnet add package
drag the dll file and drop it into the bin folder
Above answer from ikolim doesnt work as indicated by someone else too, there is no, Nuget: Install/Reference command. There is only Add Package! So the answer in the below link solved my problem. Manually editing the Myproject.csproj file.
Duplicate of this thread
I've stored the files in a project folder named "dlls" and added the reference files in my .csproj file like this:
<ItemGroup>
<Reference Include="Microsoft.Office.Client.Policy.Portable">
<HintPath>dlls\Microsoft.Office.Client.Policy.Portable.dll</HintPath>
</Reference>
<Reference Include="Microsoft.Office.Client.TranslationServices.Portable">
<HintPath>dlls\Microsoft.Office.Client.TranslationServices.Portable.dll</HintPath>
</Reference>
</ItemGroup>
In case of extisting .dll reference,
Right click project
Add existing item > select path to .dll
After added dll in project,right click .dll
build-action = Content, Copy-to-output-dir = Always/ or if newer
I'm trying to run asynchronous test methods with .NET 4.0 BCL Async and MsTest.
It seems that this setup is not able to deal with [TestMethod] async Task TestSth() due to a missing entry in the test case explorer. After changing the signature to async void, I can run the the test case but with the wrong outcome (no errors will be reported at all).
I have seen an attemt at Running Async Task unit tests with TFS 2010 but I think there should be a prettier way to tackle the problem.
Any suggestions?
You can only use the async keyword with an MSTest-referencing class library targeting .NET 4.5.
If you can't use .NET 4.5 for whatever reason, then you'll just have to live with waiting on the tasks manually.
And even if the production code (i.e. the code under test) can't use .NET 4.5, why can't the test project do so? If you already have VS 2012+ available to you, then .NET 4.5 will be installed on your development machine.
Here's a workaround that is working for me. It was a bit tricky to figure out, but finally all unit tests against my .NET 4.0 libraries are being detected and showing up in Test Explorer, running and passing, and they're all written as normal async Task methods, without any special test runners, wrappers or third-party dependencies.
Change the target Framework of your unit test project to .NET 4.5.
Yes, you must do this even if the project references that you're testing target .NET 4.0.
Remove the Microsoft.Bcl, Microsoft.Bcl.Build and Microsoft.Bcl.Async NuGet package references from your unit test project. If you haven't added these references, then simply do not add them to your unit test project.
Add System.Runtime.dll and System.Threading.Tasks.dll to your unit test project as linked files in the project's root directory.
Right-mouse click your unit test project in Solution Explorer.
Add > Existing Item...
Browse to your solution's packages folder and locate the net40 package folder for Microsoft.Bcl; e.g., ...\packages\Microsoft.Bcl.1.1.10\lib\net40\
Select All Files (*.*) in the file type drop down.
Holding the Ctrl key, left-mouse click System.Runtime.dll and System.Threading.Tasks.dll to select them.
Click the small drop-down arrow on the Add button. (Do not click the Add button.)
In the Add button's drop-down, click Add As Link. Both assemblies are now visible at the root of your project.
You must leave the assembly links at the root of your project. Do not move them to a subfolder.
If your project is under source control, then you may notice that these linked files are marked as excluded (and if they aren't, they should be.) The NuGet packages folder, where these files reside, should not be checked into source control. Since they are merely linked files, anyone pulling down your changes should have no problems at all after restoring their NuGet packages.
Select both of the linked assembly files in Solution Explorer (Ctrl + Left click) or simply perform the following steps on each file separately.
Right-mouse click either of the selected files and select Properties. The Properties window opens.
Set the Copy to Output Directory field to Copy if newer.
Your unit test project file should now contain something similar to the following.
<ItemGroup>
<Content Include="..\..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.Runtime.dll">
<Link>System.Runtime.dll</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<Content Include="..\..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.Threading.Tasks.dll">
<Link>System.Threading.Tasks.dll</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
And that's it!
Just keep in mind that your unit test project targets .NET 4.5 (or a higher version, if you'd like) and so unit tests can use async methods and any other .NET 4.5 features. There shouldn't be any conflicts with the .NET 4.0 assemblies that you're testing, but if you do find conflicts, it's probably because you've redefined some types for newer Framework/C# features and made them public, thus causing conflicts when you try to use those same types in your unit tests. The best solution is to simply make those types internal to the projects you're testing.
Edit:
After following those steps, you may get some build warnings:
All projects referencing My.csproj must install nuget package Microsoft.Bcl.Build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317569
{root}\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets
To avoid these warnings, simply edit the unit test project and add the following metadata element to each project reference that points to a project that references Microsoft.Bcl.Build.
<Properties>SkipValidatePackageReferences=true</Properties>
For example:
<ProjectReference Include="..\pcl\pcl.csproj">
<Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project>
<Name>pcl</Name>
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
The full explanation can be found in the noted .targets file included with the Microsoft.Bcl.Build package. Here's the full comment, for your convenience.
BclBuildValidateNugetPackageReferences
This target validates that any Nuget packages installed in the current project are also installed in projects
referencing the current project.
This is necessary because Nuget packages contain more than just simple references. Installing the package ensures
1. The right set of references for the target framework are added
2. Config file transforms are applied
3. Project installation scripts are run
For all packages listed as installed for the current project in packages config, if the package ID matches one specified in #(ValidatePackages), ensure that the same package is installed in the referencing project.
This target can be disabled for a project reference by setting SkipValidatePackageReferences=true for the reference:
<ProjectReference Include="..\pcl\pcl.csproj">
<Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project>
<Name>pcl</Name>
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
This target can be disabled for all references to a project by adding the following:
<PropertyGroup>
<SkipValidatePackageReferences>true</SkipValidatePackageReferences>
</PropertyGroup>
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.
I'm working with a large (270+ project) VS.Net solution. Yes, I know this is pushing the friendship with VS but it's inherited and blah blah. Anyway, to speed up the solution load and compile time I've removed all projects that I'm not currently working on... which in turn has removed those project references from the projects I want to retain. So now I'm going through a mind numbing process of adding binary references to the retained projects so that the referenced Types can be found.
Here's how I'm working at present;
Attempt to compile, get thousands of
errors, 'type or namespace missing'
Copy the first line of the error
list to the clipboard
Using a perl script hooked up to a
hotkey (AHK) I extract the type name from
the error message and store it in the windows clipboard
I paste the type name into source
insight symbol browser and note the
assembly containing the Type
I go back to VS and add that
assembly as a binary reference to
the relevant project
So now, after about 30 mins I'm thinking there's just got to be a quicker way...
These solutions come to my mind:
You can try to use Dependency Walker or similar program to analyze dependecies.
Parse MSBuild files (*.csproject) to get list of dependencies
EDIT:
Just found 2 cool tools Dependency Visualizer & Dependency Finder on codeplex I think they can help you greatly.
EDIT:
#edg, I totally misread your question, since you lose references from csproj files you have to use static analysis tool like NDepend or try to analyze dependencies in run time.
No, there currently isn't a built-in quicker way.
I would suggest not modifying the existing solution and create a new solution with new projects that duplicate (e.g. rename and edit) the projects you want to work on. If you find that the solution with the hundreds of projects is an issue for you then you'll likely just need to work on a subset. Start with a couple of new projects, add the binary (not project) reference and go from there.
One thing you can try is opening up the old .csproj file in notepad and replacing the ProjectReference tags with Reference tags. If you can write a parser, feel free to share. :)
Entry in .csproj file if it is a project reference
<ItemGroup>
<ProjectReference Include="..\WindowsApplication2\WindowsApplication2.csproj">
<Project>{7CE93073-D1E3-49B0-949E-89C73F3EC282}</Project>
<Name>WindowsApplication2</Name>
</ProjectReference>
</ItemGroup>
Entry in .csproj file if it is an assembly reference
<ItemGroup>
<Reference Include="WindowsApplication2, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<ExecutableExtension>.dll</ExecutableExtension>
<HintPath>..\WindowsApplication2\bin\Release\WindowsApplication2.dll</HintPath>
</Reference> </ItemGroup>
Instead of removing the project files from the solution, you could unload the projects you aren't working on (right-click the project and select Unload Project). As long as the unloaded project has been built once, any other project with a reference to it will be able to find the assembly in the project's output directory and build with it.