I created a setup project using Visual Studio 2010. I accidentally checked the "Permanent" property on one of my dlls, not realizing what I was doing. From here, I've learned once you turn that setting on, turning it off will not fix the problem. The file I originally marked Permanent will never be removed on an uninstall even though I've changed the Permanent property back to false. But, there's gotta be a way, right? There has to be something in the registry but I'm not finding anything. Any ideas?
I just did a search for my dll in the whole registry and deleted every node with a reference to it. I'm not sure which one did the trick. None of the property names were obvious enough to say that the file was "permanent".
Related
Recently, whenever I change something in my code, rebuild, and attempt to debug, I get the error "This breakpoint will not currently be hit, No symbols have been loaded for this document."
But then as soon as I restart my computer, everything is fine and I can debug properly. Why is this happening? It's really frustrating having to restart my desktop every time I try to debug my code. I've looked all over stack overflow and MSDN and can't find any solution to my particular problem. Any help is appreciated
"This breakpoint will not currently be hit, No symbols have been loaded
for this document."
(As for this error message, it's common error which has different causes. I can't give the most direct correct answer for this issue, I can only give you some tips for trouble-shooting. In order to avoid losing contact in the round-trip comments, I post those content as answer instead of comments.)
Since VS2015 have been released for long time, I would think this issue is a particular one, not found similar issues online.
First of all, please create a new simple project to check if this issue occurs in new project when debugging.
If it persists in new project, I think this issue has something to do outside environment like VS settings, VS config files or Debug options.
You can try:
1.Go Tools=>Import and Export Settings=>Reset all settings =>No,just reset settings=>Finish
2.Repair VS IDE since it seems to work well in the past, and just got the issue recently, so maybe something is broken for your IDE(In Control Panel find VS2015, right-click=>change=>repair). Also, make sure you have the latest VS2015 Update3 instead of earlier versions.
And if it works well in new project, then maybe the issue is about the whole project or solution itself. You can try:
1.Navigate to solution folder, close all vs instance, delete the .vs, bin and obj folders and restart VS to check if it helps.
2.Make sure you've loaded the required symbols, check the content in your Modules window during debugging, there's possibility you don't load necessary symbols successfully.
3.Check the output folder after your rebuild, check in folder like bin\debug folder if you have both the .exe and .pdb files. And make sure the .exe and .pdb files are up-to-date after your rebuild by checking their Date Modified.
Hope it helps and more info about the project type, dependencies would be better:)
Question says it all. I'm trying to write a Visual Studio addin (2012), and the experimental instance always launches without running anything in the addin. No breakpoints are hit in the main instance, nor does the addin get loaded by the experimental instance.
I should point out: it worked at one point once or twice, then I deleted the project since I thought it was the wrong kind of project, but ended up recreating it with the same name.
No amount of fiddling with "allowing addins to load" or resetting the experimental instance or cleaning the registry manually fixes the problem. I also tried looking for my addin dll, but it wasn't in the list. I'm totally out of ideas and possible search terms. Any suggestions?
I had the same problem as you and have just discovered the fix for me, it relates to the new "file properties" entry in the add-in project that gets supplied.
If you open this file which is in my case called "[App Name] - For Testing.AddIn" you'll see XML markup containing things like the AddIn friendly name, description e.t.c.
For me I found that I'd immediately renamed the output assembly for my project and this no longer matched that found inside this properties file:
<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>11.0</Version>
</HostApplication>
<Addin>
<FriendlyName>My Addin</FriendlyName>
<Description>My Addin description.</Description>
**<Assembly>E:\Workspaces\Scratch\MyApp\bin\MyApp.VisualStudio.Addin.dll</Assembly>
<FullClassName>MyApp.VisualStudio.Addin.Connect</FullClassName>**
<LoadBehavior>1</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
I checked the name of the assembly and class names fixed them up, saved the file and hit debug and it all started working again! Hope this helps...
I had a similar problem... fought with it for quite a while, and eventually, absolutely randomly experimented with adding other configurations to the project (Configuration Manager) and also changing the framework.
One of the two magically helped. (I think it may have been the framework... though it makes no sense).
I am not saying that the same thing will work for you.
The random experiment was not really random: I got hold of a "debuggable" add-in off the web, and compared every single item in the project, solution and all other files, to find what could be different. This is my true suggestion.
If all else fails, you can also try to manually attach the debugger, see if you can make headway this way. [ that did not work for me, but it may provide valuable information, and... not all bugs are created the same. ]
Seems like there are different solutions to this problem but this finally helped me:
Changing <LoadBehavior>1</LoadBehavior> to <LoadBehavior>0</LoadBehavior> in the AddIn-file and put it manually in C:\Users[UserName]\Documents\Visual Studio 2012\Addins
Restarting Visual Studio (I use 2012)
Complete AddIn-file:
<?xml version="1.0" encoding="UTF-16" standalone="no"?>
<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>11.0</Version>
</HostApplication>
<Addin>
<FriendlyName>[Friendly Assembly Name]</FriendlyName>
<Description>[Description of the Addin]</Description>
<AboutBoxDetails>[About details]</AboutBoxDetails>
<Assembly>[Full path to the binary e.g. C:\Test\debug\test.dll]</Assembly>
<FullClassName>Test.Connect</FullClassName>
<LoadBehavior>0</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
</Extensibility>
In my case I moved to a different developer machine where it was previously working on the old machine, but on the new machine I didn´t have any '[Assembly Name] - For Testing.AddIn' since I didn´t bother to check it in. I think the LoadBehavior is the difference between For Testing and the regular AddIn.
I had the same problem. Debugging worked until I closed all instances of Visual Studio. I then opened Visual Studio again and it said that the add-in that I had been debugging had stopped working. When Visual Studio asked whether to remove it, I said yes.
Apparently removing the add-in in this ray renames the "[AppName] - For Testing.AddIn" file to have an underscore appended.
To fix the problem, go into the add-in solution and look at the properties on the "[AppName] - For Testing.AddIn" file. Go to the folder where the file is located. Rename this file in the file system to match the name of the file in Visual Studio.
In my case, Resharper was the reason. Everything gets back to normal after disabling Resharper.
I have some tests that were marked as [Ignore], but now, I want to run them again, so I remove the [Ignore] attribute, but Visual Studio still treats them as ignored.
What can I do to clear the cache to not ignore the tests anymore?
Update:
It looks like this data is stored in the vsmdi file:
<TestLink ... name="MethodName" ... enabled="false" />
So deleting the vsdmi file, or otherwise causing it to be regenerated is necessary.
But, visual studio caches it, so restarting visual studio seems to fix the problem (sometimes at least).
We have this issue where I work as well.
You can manually change the .vsmdi file or delete it. If you open the test view again (after deleting it) it will generate a new file.
Also, the same kind of issue can occured with which test settings you have selected. It will 'cache' that as well.
Have you tried Clean Solution (in the build menu)? Also I would try deleting the bin/obj folders from the test-project. If that doesn't work I'd look for other (binary) files that might be a cache of some sort or related to test-projects and just delete them. I can't imagine it to be hard to locate such files and just delete them (make sure you have a backup, just in case).
EDIT Apparently it's the .vsmdi file.
EDIT2 Apparently not :P
If I would've encountered such a problem I might even have done a filesearch looking for specific method-names that have been [ignored]. Make sure you use a tool that looks "inside" every file, windows file-search ignores a crapton of files.
Even while this topic is quite old, I'd like to add my solution to this problem, for anyone who's having the same problem...
I recenlty had this problem also, and found the solution in the .vsmdi file.
Under 'Test Settings', 'Unit Test' a had a folder referred in 'Root folder for the assemblies to be loaded:' and the checkbox 'Use the Load Context for assemblies in the test directory' was checked.
I unchecked the checkbox, and after that, my tests did run succesfully! (I knew the files referred in 'Root folder....' where old assemblies.
You can also remove the files from folder in 'Root folder...' to make sure your old assemblies are removed.
I was using Visual Studio 2012 and did not have a .vsdmi file but ran into the issue. I was able to solve this by deleting the .suo (hidden file next the .sln file) file and restarting the Visual Studio. I know it says without restarting but the provided solution didn't work for me so I am providing an alternative in case someone else runs into the same error.
Every time I open a particular solution, the VSS bindings are lost and I have to rebind. Can anyone tell me why this happens and/or how to prevent it (short of never closing the solution, or having to do a "Get Latest Version")? This doesn't happen for every project/solution, only this one.
As always, thanks for the help.
P.S. I know the product sucks, but I have to use it.
It's gonna be hard to find the root cause of the problem but it's probably related to corruption of binding informations stored in your folder.
One possible solution would be to delete the content of your project folder (you can try first by only removing VSS related files) and then re-open it from source control (in VS) to let VS recreate binding informations.
This will surely work if only you in your team are experimenting this problem... othewise... don't know.
If the problem still occure after that, I don't see other solution than re-installing your VS :-(
Hope that help !
which version of VSS are you using?
In older versions of Visual SourceSafe (before 6.0c), after adding a solution of Visual Studio to its source control, the binding information was stored directly in the .sln and .proj files.
Since VSS 6.0c, all binding information is kept locally in files named MSSCCPRJ.SCC on the developer's machine.
after deciding where the binding info is stored, you can pinpoint the cause easier. before and after closing VS, open the .sln/ file with notebook and check whether it includes code similar to
GlobalSection(SourceCodeControl) = preSolution
...
EndGlobalSection
It may be because something might be intefering with the local copy of VSS solution on your machine.
The local directory set for your solution contains two additional files besides your project files:
one is MSSCCPRJ.SCC and the other is TheSolutionName.VSSSCC.
In windows, their icons are in the form two arrows pointing in opposite directions.
I had accidentally deleted them (thinking they were junk) and then lost all bindings to the VSS solution. Please check if something similar is happening on your machine.
Another reason could be - using multiple versions of VSS on same machine.
This is driving me crazy and has resulted in lost work (not much, at least).
Normally, when I edit a file in Visual Studio, it's supposed to automatically check that file out in source safe. On multi-project solutions (e.g., web app with class libraries), sometimes none of the files in one project would automatically get checked out, though exiting & reloading visual studio may fix that problem temporarily. Furthermore, project files are never automatically checked out. Whenever I add/remove code files, I have to remember to explicitly check out the project file as well (otherwise we'll have issues with code files not showing up in the solution explorer, or trying to load non-existing files).
We're using VS-2008 and VSS 2005. Do you have any idea how I might fix this? There are no more visual-studio updates/fixes on Microsoft Update.
You need to ensure the files are read-only, or VS won't be able to tell that they are version controlled (or, at least that's what it uses to determine it). You can tell VSS to set itself up so getting the latest version places the files RW on disk.
There may be other problems here, but that's what comes to mind first. My advice (that I took myself) is to migrate to SVN or an alternative. Losing work is unacceptable.