CODEWITHSUNDEEP
visual-studiovisual-studio-2012add-invisual-studio-addins
gzak
gzak

Reputation: 4110

Can't debug Visual Studio addin

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?

Upvotes: 10

Views: 2904

Answers (5)

Khoa Nguyen
Khoa Nguyen

Reputation: 1086

In my case, Resharper was the reason. Everything gets back to normal after disabling Resharper.

Upvotes: 0

GaTechThomas
GaTechThomas

Reputation: 6076

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.

Upvotes: 1

Marcus
Marcus

Reputation: 8649

Seems like there are different solutions to this problem but this finally helped me:

  1. 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
  2. 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.

Upvotes: 1

The Senator
The Senator

Reputation: 5391

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...

Upvotes: 3

Thalia
Thalia

Reputation: 14605

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. ]

Upvotes: 1

Related Questions