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.
Related
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 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.
I create my first TFS (2013 Express) project and added my solution (MVC5) to that project.
I then checked everything in and deleted it and restored from TFS to ensure that I have a working copy.
It was at this point I realized that I have a "DLL Reference" folder that sits outside of my solution.
What is the proper way for storing 3rd party dll referenced like this in TFS so that I can ensure I have a working solution?
EDIT:
This is not dll's from Nuget. These are 3rd party dll's that I am referencing from a folder.
Create a folder in TFS at solution level, call it dependencies, binaries or give any name you prefer. Add 3rd party files to this folder. Remove and add references to your project from this folder.
The easy-though-not-so-clean way is to create a dummy project, with no source files and a single folder (you could use the assemblies folder you already have) containing your dependencies. You can then add the dummy project to your solution and it will be synchronized by TFS.
There is an alternative solution, without including a dummy project.
From within Visual Studio, you can use Source Control Explorer to add files to TFS even if they are not in a project of your solution.
You can also do this from Windows Explorer. As long as you are in a folder that is part of a configured Workspace, you should be able see a "Team Foundation Server" drop-down menu when you right-click the folder.
The downside to this is that when someone needs to download your solution files to a new machine, they will have to manually download that folder too (via Source Control Explorer or Windows Explorer).
I know I'm a bit late to the party, but for anyone having a similar problem, you can create a folder in your project called "ExternalDLLs" and add the DLLs you need in there. Add references to these DLLs in your Project. Then include this folder in your Source Control and Push it up.
By default, Source Controls, ignore files with certain extensions (e.g. dll). Ensure that you add this folder to the Source Control, you can usually do it from your IDE or there may be a .gitignore file (or similar)
If you are trying to Push the bin folder with the DLLs up to your Source Control, the bin folder contents become Read-Only. That is why, this separate folder needs to be created.
I always recommend against committing binaries to source control. One way you can maintain these dependencies is to create your own nuget package, and host it internally on your own nuget server.
I downloaded a VS2013 project from a Git repo. The repo does not include the assembly references inside it. However, I have the SDK that contains all of the references I need for the project. The problem is that the path for the references is empty. Currently I'm having to remove and re add each assembly one by one and it is wasting too much time.
Is there a way to set a path to the folder that contains all the references and have the VS project find and update them automatically?
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?