I have this dll (Microsoft.web.Infrastructure.dll) in many project's package.config of my solution. There are no build errors and the dll is getting downloaded to Solution's packages folder.
I am getting runtime error on missing dll on each of the project the application hits. When I look at the individual project bin folder, I don't see this dll copied. However as I mentioned earlier the dll is downloaded to packages folder of solution.
Temporary Solution -
Manually copy this dll to all individual project bin
Place this dll in GAC
This problem is only on my machine and not on any other colleague's machine. Surprisingly some of them have this dll copied into project folder while some of them don't. It works for them without this dll in GAC and without any manual effort, a clean rebuild did everything for them.
I have a short term fix but I am more curious to know how it working on other machines and what I am missing.
Things that I have tried so far -
Clean Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root....
Clean solution and close reopen solution and finally Rebuild solution
Visual studio 2015 doesn't have clear nuget cache as compared to visual studio 2013.
FYI - I have Visual Studio 2015 and all other machines are on 2013, if not something else this is where I am looking at now.
Any help is appreciated.
Please check whether the Microsoft.web.Infrastructure.dll is exist in the Project References. If not, please try Win’s suggestion to reinstall your package in the Package Manager Console by following command:
Update-Package –reinstall Microsoft.Web.Infrastructure
Because the NuGet Restore only restores packages based on the package.config file to the packages directory, but does not add the reference to your project by default. So we need to force reinstall the package to add references and content files into project.
If the dll is already existed in your Project References, you need to check the property value of “Copy Local”. The Copy Local property determines whether a reference is copied to the local bin path. The CopyLocal=True should be set if the reference want to be copied to bin folder. See Set the Copy Local Property for more detail.
I found that my team used to have dll's in the bin folder but wasn't checked in, but the project file still had references pointing to those deleted dll's. What happened was I still had those dll's in my bin while nobody else did, and those dll's depended on microsoft.web.infrastructure existing, so I was the only one getting that error.
For me, those dll's (references) were:
System.Web.Razor
System.Web.WebPages
System.Web.WebPages.Deployment
System.Web.WebPages.Razor
So instead of modifying references in the the project file (It'll be on a different check in), I just deleted those dll's in my bin, and no more dependencies on microsoft.web.infrastructure.
Related
I have a Visual Studio solution, containing multiple projects. To some of these projects, I had referenced a Shared Project, which has since been deleted. However, the Visual Studio project seems to still be referencing this deleted Shared Project.
A specific type I am using is present in both the Shared Project and a referenced NuGet package. Even though there is no sign of the Shared Project anywhere in the dependencies, I still get an ambiguous type error. Furthermore, when using Intellisense autocomplete in the project's .cs files, the Shared Project will be autocompleted. However, when I search through the entire solution by the Shared Project's namespace, there are no results. What's even more strange, is that the entire folder the Shared Project was in, has since been deleted. The files are literally not on my disk anymore.
I have tried deleting all bin and obj folders, as well as the .vs folder, but nothing changed.
It seems this shared project is also referenced by a NuGet package I am using. In the latest version, this shared project is (obviously) deleted, but in the old version it is still present. This was the cause of my issue. I have updated the package and now everything is fine. Thanks for the input.
when restoring a locally created nuget package I receive the following error:
Failed to add reference to 'Microsoft.Data.SqlClient.SNI.x64'.
Please make sure that the file is accessible, and that it is a valid assembly or COM component
When I look at the nuget build I see the following
click to enlarge
The highlighted yellow "missing" dlls in the screenshot above do actually exist in the project.
I am using Visual Studio 2017 professional
Thanks for any help
Mark
Nuget package update - Microsoft.Data.SqlClient.SNI.x64
Please try the following steps:
1) close VS Instance, delete nuget.config file under C:\Users\xxx(current use account)\AppData\Roaming\NuGet.
2) delete .vs hidden folder under your solution folder, bin and obj folder then restart your project to test again.
3) Please try to create a new empty project in VS2019 and test whether you can install the package Microsoft.Data.SqlClient.
If you cannot install it, you should note that whether your VS or OS has broken. If the new project has no error, the issue is your project itself. You can try the above steps to troubleshoot the issue.
If the issue still persists in the new project,
You can try to repair VS or update VS to the latest version.
Also, try to update OS or use the System File Checker tool to repair missing or corrupted system files.
Besides, try another PC to test whether the issue persists.
Microsoft.Data.SqlClient.SNI.X64 or X32 files need to be removed from release folder before creating package.
Microsoft.Data.SqlClient.SNI.X64 will be added automatically while adding Microsoft.Data.SqlClient.
So, remove the dll before creating the package and then try installing it.
I am using Visual Studio 2017 Enterprise, C# 4.7.2
My Solution contains currently nine different projects. A build succeeds without any error messages. When I run the application, a TypeLaodException is thrown, The Type Namespace.AClassName could not be loaded.
The weird thing is, that there isn't any class named AClassName anymore. BUT, the mentioned class did exist in a former version.
I cleaned the solution, startet a build, same error. I rebuilt the solution, same error. Cleaned than rebuilt the solution, same error.
Apparently, the build is not correct. But what can I do to ensure, that the build runs correctly?
If manually deleting the folders bin and obj as suggested in the comments is not working, I will also delete de .vs and there are a few things you can try:
Unload the projects, and search in the .csproj for any reference to
the Old-Deleted AClassName. Check also that there is no namespace related to it. You will have to do it in the project where originally was the class, but I will recommend to search in all 9 projects.
Check if there is any Project Dependency in the Configuration Manager related to the project where the AClassName was.
I would also restart my machine, delete temp folder and run VS As administrator.
Clean Solution.
Clean Debug & Bin folder.
Make sure all project reference are from Project libraries (it should not be directly from Bin folder).
Make sure all interconnected project build on same .net platform (4 , 4.5 or 4.6 ).
Build and try to run.
I have read many of the answers on SO and NuGet (and the Internet in general, really), but I can't seem to overcome the problem I am having with NuGet package restore in Visual Studio 2015. I have the following scenarios.
Solution A Structure
--Project A
If I open and build Solution A I see the dialog box that shows the nuget package restore progress and the solution builds successfully.
Solution B Structure
--Project A
--Project B
However, assuming that I have never built Solution A (i.e. fresh pull from TFS), if I open and build Solution B I see the dialog box that shows the nuget package restore progress, but the build fails because Project A fails to build.
What appears to be happening is that that NuGet is restoring the packages for Project B, but not for Project A thus the build failure. To the point, if I look at the references for Project B all of the NuGet references have resolved, but the references for Project A are still broken.
A few points:
I have disabled source control integration for NuGet so I am not checking in the Packages folder.
Each project has its own packages.config file
The build order in Solution B is Project A then Project B
Thoughts would be greatly appreciated.
By default, NuGet creates the solution's packages folder in the solution root, and each project references its package DLLs to that "local" packages folder. In your example, if you open the .csproj file for Project A, you'll probably see that the reference path is something like ..\packages\[package name]\[etc].
So when you do a fresh pull from TFS and build solution B, Project A can't find its DLLs because c:\workspace\Solution A\packages doesn't exist yet (or whatever the absolute path is on your machine).
To correct this, use a shared package folder, created at c:\workspace\packages. To do this, you have to add an additional node to the NuGet.config in each solution (see https://docs.nuget.org/consume/nuget-config-file for details; I am also assuming you have a NuGet folder at c:\workspace\Solution A\.nuget):
<config>
<add key="repositorypath" value="..\..\packages" />
</config>
I used a relative path here, but you can use an absolute path as well, and the documentation says you can use %HOME% as well.
Do this, then restart Visual Studio. The next time you open the package manager, it should ask you if you want to restore missing packages, and assuming you click yes, it will put them in the new location. The last step is to edit the .csproj file and change all instances of ..\packages to ..\..\packages (or you can uninstall and reinstall the package, but I find editing the .csproj a lot faster).
To restore nuget packages do following steps:
Change target framework in project properties
Clean project
Set previous target framework
Rebuild project
I hope, it will help.
Taken from OPs question
howcheng's answer is generally correct with some caveats. After implementing the changes howcheng suggested, I was able to build all of my solutions locally using a central 'packages' folders that all projects look at, regardless of solution. The problem that I ran into though was that when I checked these changes in to TFS, my CI build kicked off and failed!
My CI Build Definition builds both Solution A and Solution B as part of the default XAML process template, not a .proj file. The errors that I was seeing seemed to indicate that Solution A was restoring its packages, but Solution B was not. If I logged onto the build server and opened Solution B in VS 2015 everything worked fine; after Googling for a couple of hours I came across this article which ended up leading me to my answer.
I am developing in Visual Studio 2015 but I am using TFS 2013 for source control and builds. Despite the fact that I have Visual Studio 2015 installed on the build server, MSBuild still references the version of NuGet that shipped with TFS 2013 and NOT with the version included with VS 2015. Once I ran nuget update -self from the TFS Tools directory my build worked correctly.
I'm working on a Web Application in Visual Studio 2012 using HtmlAgilityPack. My project references the 1.4.0.0 version of the dll in the application's bin folder. Previously it used 1.3.0.0
The application works, but about once a day the dll in the bin folder is overwritten replacing version 1.4.0.0 with 1.3.0.0. I've already checked the GAC and deleted my ASP.NET temp folders the first time this happened. Does anyone know what's going on here?
You need also delete the 1.3.0.0 dll from you solution's reference list from Solution Explorer.
The older .dll is apparently being referenced from somewhere within your solution. I would open the project file(s) in an editor and look for any references to older versions there.
If none are found, my guess would be that some other library or component you are relying on is referencing the old version of the .dll (are you using any third party libraries?). If you don't have the source for these, then perhaps you can decompile them using JustDecompile or some similar tool. Then you can at least check the references within the dll's your using, and confirm or rule it out as the source of your problem (no pun intented ^^).
Oh, and one more thing - maybe obvious, but have you set Specific version = true for the reference?