I've spent some time this weekend working on a VSIX (Visual Studio Extension) project, and about some time yesterday the experimental instance began throwing a StackOverflowException when starting debug. The exception seems to be thrown from within the JoinableTaskFactory class from Microsoft.VisualStudio.Threading, specifically from this method:
private void ExecuteJob<T>(Func<Task> asyncMethod, JoinableTask job)
Unfortunately, this doesn't seem to be an issue that is caused by the project itself, as I've tried debugging a new blank VSIX project and I'm continuing to run into the same exception. I'm really not sure what could be causing this. In the time between when I was able to debug and when I started running into this issue, I hadn't made any changes to the IDE itself (including installing other extensions or updates). I've also tried resetting the experimental instance and doing a fresh install of Visual Studio, but neither has resolved the issue.
At this point I'm pretty stumped... Any ideas?
So, I'm not exactly sure why the extension was able to persist in the Experimental instance, but it turns out even after all that it was still installed, and it was the extension after all. I had mistyped the parent of the extension menu in the command table and set it to the extension menu group, which was causing the menu to get recursively nested within itself. This was causing the visual studio search service to crash in the experimental instance with a StackOverflowException. I uninstalled the old version of the extension and everything works perfectly now.
Related
I am using WCF in my project. The project was working fine before. Suddenly it has started throwing errors. I can build the project successfully but when I run it, a lot of first chance exceptions are being thrown. Most of them are related to microlib.dll.
A few AccessViolationException in System.Web.dll and WcfSvcHost.exe are also being thrown.
All other visual studio solutions are working fine except this one.
I have tried running the project in both Debug and release mode.
I have tried deleting IISExpress folder in Documents Directory
My VS solution contains many class liberaries and all are running in Any CPU configuration.
I cannot figure out the reason what is causing the issue. I checked the microlib.dll in C:/Windows/Microsoft.NET/assembly and saw it is last modified in January.
Can anyone please help me in this?
I am writing a Visual Studio extension which targets VS2010, VS2012, and VS2013. It runs and is initialized successfully in each Experimental Instance with no issues. When I install the VSIX generated by the build, it installs in all versions without a problem, but only in VS2010 does it actually execute. In the others it's never instantiated or initialized.
There are no exceptions being thrown. Running the non-Experimental instance with the /log flag does not produce any other diagnostic information (other than confirming it is installed, and has a newer version than its counterpart already in the gallery.)
My reading and experiences suggest that this is due to some sort of missing assembly or reference, but I can't confirm that. I am also at a loss as how one would figure out what's missing, especially without an exception or log message.
I've been at this for several days now trying things like signing my assemblies, various vsixmanifest changes, changing the required framework versions, and many other things found here on SO that have not been fruitful.
Additionally, I have tried installing the old, already published version from the VS Gallery, and it also does not run. However, I have received feedback (bugs and thanks) from several individuals, so I know it works for some people. I have not received any feedback stating that "nothing happens," but do not rule out the fact that those are unreported.
I don't intend to plug, but the currently published version is here: http://visualstudiogallery.msdn.microsoft.com/5cc44f63-4ea8-4c17-8aa4-95037a2d32ef
The entire source for where I currently stand can be found on github in branch "ForStackOverflow". The difference between that and master is a TraceAppender which I used to confirm that the VSPackage was not being instantiated.
https://github.com/alexcpendleton/Pendletron.Vsix.LocateInTFS/tree/ForStackOverflow
Any suggestions, experiences, or anything would be helpful. Thank you.
Thanks to Erti-Chris Eelmaa's suggestion to enable FusionLog I was able to figure out what was going on.
Visual Studio was not looking for my extension in the installed extension's directory, rather from the GAC and elsewhere. Curiously, it was finding an included assembly just fine.
I examined the .vsixmanifest of other extensions and discovered that mine was missing a .pkgdef Content node for my project. It would seem VS2010 accounts for this, or for some other reason happened to look in the extension's installation directory for the package assembly, where 2012 and 2013 did not. Adding this content node to my .vsixmanifest allowed Visual Studio to load and run the extension.
<Content>
<VsPackage>Pendletron.Vsix.LocateInTFS.pkgdef</VsPackage>
</Content>
I had Visual Studio 2010 installed on my Windows 7 desktop, that I was using primarily to debug ASP.NET solutions. Everything was working great, until one of the Windows updates installed a new version of the .NET Framework. Now I get the following message when I try to place a breakpoint and then do a "debugger step" in my C# code:
To make matters worse, it doesn't happen all the time. I tried to find any pattern, but the best way I can describe it is sporadic.
Any idea how to fix this?
I just got this in Visual Studio 2015. I was debugging on a separate thread, hit the breakpoint but could not continue. A reboot did not fix it.
I deleted all of my breakpoints, reset the two that I actually wanted and it works!
Can I suggest you try using the resharper test runner. I have also been hitting this error a lot in VS2017 15.5.2 I have found its something to do with the VS test system.
Even though this solution is a product recommendation (I don't work there) it solved my issue and I was able to get things debugged.
The problem I have run into twice now is that my program seems to be running code that no longer exists. I figure that some old version is stuck some how but have no idea how to get the compiler to run the updated code I've written.
The way I have spotted the problem is by observing that bit maps I've loaded keep getting drawn even after I've removed instructions to do so. The problem persists even after removing every reference to the image in question, content load lines included.
The first time this happened restarting the compiler didn't fix the problem but restarting the computer did. Now the problem has persisted after a full shutdown.
I m using ms C# 2008 express edition if that has any bearing.
My first thought would be that the build is failing and that Visual Studio is running the old version. I don't have VS 2008, but in VS 2010 the option to change this option is in Tools->Options->Projects and Solutions->Build and Run.
You have to figure out where the mismatch is coming from.
What happens when you run the .exe from outside VS? What about from inside VS? Can you verify that after a build, the binary you're executing has an updated timestamp? Is the stale code in a .dll where the new version isn't getting pulled in?
In my experience this happens when configuration profile is changed from debug. For instance if I am running the debug profile, it works. Then I change to the QA profile and make changes and then build the new assemblies. The assemblies are built to a directory called "QA" however, when I debug through visual studio it runs the code from the debug profile. I can remove references, recompile the code, visual studio will still run from the debug profile. It appears that none of the changes I made are in the code. When in reality I'm inadvertently running a old build.
I'm working on a VS2010 Solution containing an ASP.NET Website Project and 8 c# class libraries. All projects are set to compile under .NET 3.5
When I set a breakpoint somewhere in the class libraries, the debugger breaks correctly and everything is fine. If I then stop debugging, modify code in the class library, and start debugging again (which of course rebuilds the libraries which were modified) the debugger ignores the breakpoints.
Has anyone else experienced anything like this? I'm lost and it's extremely frustrating to not be able to debug after making even a single line change and rebuilding.
Visual Studio 2010 Ultimate
Windows 7 Professional 64-bit
Be sure that you are killing your webdev server instance. If the breakpoints that are not being hit are in server code a new debug instance won't automatically attach to it.
I encountered this issue - the only way to resolve it was to recreate the solution by importing the existing project into the new solution. Not an ideal workaround but better than googling for an entire day and not being any better off!