I've got a weird issue that seems to be slowing down my project. I installed the Ninject NamedScope extension into my project, but later found out I didn't need it and removed it. However, when I run the project at the bottom of visual studio it tells me loading symbols for Ninject.Extensions.NamedScope, and then it tries to look for them quickly in various places which seems to be make my site pretty slow.
I've searched my entire solution for any references to NamedScope, nothing. I've checked my packages.config, nothing. I've checked the references, not there. I've even checked the .dlls in the bin folder, not there either.
So why is it trying to load symbols from something I removed and how can I get it to stop? It's noticeably slowed down my page load times.
Here are some pictures to show what occurs every page request in visual studio when debugging:
So why the heck is it trying to look in Windows\dll for this extension? When I search for any reference to NamedScope in the entire solution I get this:
Anyone have any idea??
I had a similar issue. It was caused by a stale .dll and .config in my bin folder . (I had renamed the Output assembly earlier ) Deleting the files resolved this issue.
Might help.
Related
I am working on a C# program that utilizes EntityFramework, I've cloned the program from git repo, but now it is having that dreadful Metadata file 'EntityFramework.dll' could not be found error. I have searched and tried countless suggestions for this kind of problem, but none worked. I've already checked that the reference to EntityFramework.dll in the .csproj files are correct and it is definitely there under the packages\EntityFramework.6.2.0\lib\net45\ folder. So I am not sure what else to try.
Ok, I've resolved this problem. Here is what happened. Apparently, when cloning into local directory, one of the folder on the path has a space in its name (like My DSS), and this nuget issue seems to indicate the inability of nuget to find package with space in path. So, once I changed that folder's name to MyDSS, it compiled successfully.
please have a look on the bin folder ,sometimes the dlls do not exist there .
This typically happens when teams check in files that should not be checked in (such as the .suo file) or have "optimized" their builds to exclude rarely changed projects. (unticking projects in the configuration manager.)
Another common cause for missing references is when devs reference a dependency from a /bin folder instead of the packages folder, but it sounds like you've confirmed that isn't the case.
Other questions such as Metadata file '.dll' could not be found list a number of things to check, so your problem will surely be one of these. Try building each project individually, working from projects that have no project dependencies upwards to the main application project(s). Ensure they're running the same .Net versions, check the solution NuGet packages for dependencies with "multiple versions" and consolidate these so that the solution is using a single version of each dependency. (generally good for cleaning up) Also look at .config files for version re-directs that sometimes get zombified in source control.
In Visual Studio, on top, click on Build -> Configuration Manager. Make sure that the build checkbox next to your project is checked. In case it already is, uncheck it and then make it checked again. Clean your Solution and Build it again after this.
I have been working with multiple projects (3-5, 1 exe, rest dll) in a solution and have not had any problems till now. Now one of my projects (dll) won't debug in the solution. The exe and two dlls are c# and the rest are vb. The vb dlls are the ones that won't work now. We have just changed source control and I dropped and added the projects back together and that is the biggest difference. Since then I am receiving "the breakpoint will not be currently hit. No symbols have been loaded for this document", error. It is not showing in the debug->windows->modules and so far I have added it and dropped it, reset references to all solutions, rebooted and researched all over the internet. Also, I am working with Visual Studio 15.
The dlls have not been loaded to the process which you are trying to debug, under project properties check if optimize code is checked-in this will cause VS to see assembly as "not my code", it will not load symbols for it.
Ok, finally got this to work, thanks to one of my co-workers. I was referencing the dll from the bin folder in my exe. We deleted the reference and created a new reference linking it directly to the debug folder of the dll. I could then step into the dll.
I have a very small, simple ASP.NET MVC app (MVC 4 I think. .NET Framework 4) it consists of one controller with one action serving one page.
I'm deploying it on AppHarbor, pushing it with git on my local machine, I've never had problems running it locally and it has never had build issues/errors on AppHarbour but every now and then a new build (with no relevant change in my mind) will start throwing the following error:
Could not load file or assembly 'Microsoft.Threading.Tasks,
Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Looking into this the top answer here sorted it, I removed the dependent assemblies listed and it worked again. But then it came back. Tried a lot of different suggestions, it has always used nuget, tried removing everything and re-installing, it started working again when I wasn't even sure what I'd changed and now it isn't working again. Today I switched it to NuGet Package Restore as outlined here but that hasn't made any difference.
I can re-deploy the last working build, what I notice comparing working/not working builds downloaded from AppHarbor is that the Web/App.configs are identical (no dependent assembly entriy for this) but the Microsoft.Threading.Tasks dlls and xmls (including Extensions and Extensions.Desktop) are not in the broken build (in the working build they appear in the root and in the bin)?
In the project the dlls are linked from the packages folder for the app and Copy Local is True, they aren't a direct dependency of the Web App but of the Google Calendar API its using.
Update
On the back of writing the answer I've looked more closely at the build logs and noticed a distinct difference between a working and not-working build.
The Microsoft.Threading.Tasks.dll is not a direct dependency, its required by Google.Apis.Gmail.v1.dll, in a working build the build log will contain (see the bottom line copying Microsoft.Threading.Tasks.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\voz3srsa.vhb\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\voz3srsa.vhb\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\voz3srsa.vhb\output\log4net.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.dll"
to "D:\temp\voz3srsa.vhb\output\Microsoft.Threading.Tasks.dll".
A not-working build will have a different dll in its place (see the bottom line again, Microsoft.Web.Infrastructure.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\0kzqakoc.4jo\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\0kzqakoc.4jo\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\0kzqakoc.4jo\output\log4net.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll"
to "D:\temp\0kzqakoc.4jo\output\Microsoft.Web.Infrastructure.dll".
Looking into dlls missing in the build I found this answer but I have tried a command prompt build locally and it works fine.
Update 2
Also in trying to solve this I had noticed a comment on the build (not a warning) around reference versions:
1> Consider app.config remapping of assembly "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" from Version "4.5.0.0" [C:\Users...\packages\TweetSharp.2.3.1\lib\4.0\Newtonsoft.Json.dll] to Version "6.0.0.0" [C:\Users...\packages\Newtonsoft.Json.6.0.6\lib\net40\Newtonsoft.Json.dll] to solve conflict and get rid of warning.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
Couldn't get a remapping that sorted it but did get this where adding an app.config (which makes no sense for a web app) redirect fixed it where the redirect in the web.config didn't. This did stop the build issue but made little sense.
I took this to the AppHarbor support forum as this didn't get any response here, Build succeeding but missing dll and they were very helpful and it now looks like it is resolved.
Although in Visual Studio 2012 Professional all references were marked as Copy Local True, they did not have the True tag so I added these by hand for the three libraries in question. And that was it, DLLs copied.
There are a lot of links around this discrepancy, that MSBuild needs them (although I had tried an MSBuild build and it was fine), Visual Studio doesn't insert them by default (may appear if you toggle the setting false and then true) and it manifests in not copying references-of-references.
Stack Overflow question, see highest voted answer not accepted hack
Raised with Microsoft and closed as not reproducible
I have been working on an ASP.NET project for months now without issue. Recently my computer crashed mid compile and now when I load and run the project I get 'Could not load file or assembly 'Ionic.Zip' or one of its dependencies.'
Thinking it was an issue with that particular DLL, I removed it as a test only to have the project say it could not load another referenced DLL, etc etc, until I had no references left...
Any ideas?
If nothing in the code has changed. "Build->Rebuild Solution" should do the trick (implicitly cleans and builds).
If this does not work, do "Build->Clean solution" and go delete all generated build folders (default bin and obj folders). And then try build and run.
And if it still does not work, the code has changed and dependencies are really missing.
Using NuGet and packages are missing perhaps?
I tried everything but NuGet, I didn't use it to get any of the references before.
In the end I had to check in all my changes to TFS, delete the project from my workspace and computer, and then reload it from TFS. Seems to have worked. Something must have been damaged in the project file.
I've got a C# project in visual studio that is building a DLL, and another console project which includes the first as a reference. These are both in the same solution.
The trouble is when I add methods to the DLL, then rebuild the console project doesn't seem to pick them up.
For example, in the DLL I have a class Converters. If I add a method
public static void test() {}
it just doesnt' show up in the console app at all. Intellisense doesn't autocomplete it, and if I manually type it in it gives a compiler error.
If I go in and delete the dll files then rebuild that works (or better yet, delete the bin and obj directories) but that seems rather drastic.
I'm sure this is a basic error, but I can't seem to find the solution after some googling.
How are you adding the reference? As a project reference or by browsing to the DLL? If you're using the latter then it will copy it locally to the bin directory of your console app and won't refresh it unless you manually delete it. If you add it as a project reference it will copy it as and when it needs to.
The exact thing happened to me once on a project - it turned out the build command wasn't configured to build these DLLs.
Check Build - Configuration Manager, and make sure the project is checked:
(Image from msdb - Setting the Build Configuration)
close Project visualStudio and
rebuild again your dll (other project visualStudio)
One of the things to note is the Target Framework of the Projects, if you compile your Project A with target framework different then that of Project B and it is referencing the dlls of Project A you may run into this kind of trouble. So, make sure that the target framework for both Projects is same.
Check that you don't have the ddl inside the bin folder of your project. Whilst I was adding the reference by browsing for the dll, I had forgotten that I manually copy pasted a version into that folder. No matter how many times I cleaned and rebuilt, it didn't seem to update.
Deleting that dll and re-referencing fixed the issue.
Change the reference to the dll to the Project, instead of the output.
This is certainly unexpected behavior. It sounds like the reference between the two projects is broken in some way. Two issues come to mind.
Possible problem with the reference. Try deleting the reference in solution explorer and readding the reference and seeing if that fixes things. When you re-add make sure it's a project reference and not a file reference.
It's possible that the time stamps on the files in your project are off. See if they are in the future.
check the folder which contains the reference. does it contain a refresh file with a relative path in it? if so, and if assembly names in the location pointed to by the relative path are common with those in of (project) references which should auto update, then these references no longer auto update! what you end up is a static reference to the assemblies present in the relative path contained in the refresh file.
you may also have to delete the projectreferences key in the sln file and add references afresh
I hate to beat a dead SO question but 8 years after the original question and none of the above solving the issue for me, my problem was in VS2013, but to solve it I simply removed and re-added the reference to the DLL in the project that invokes it.
I hope this helps some people in the newer VS realm having the same issue.