locked
VS 2019: running an extensibility project (VSX) always compiles an unknown external project. RRS feed

  • Question

    1. I created a fresh project in Visual Studio 2019 using the VSX c# template.
    2. I moved a bunch of files from an older VSX project (for VS 17).
    3. I compiled and ran the project - errors started emerging.
    4. I addressed one error, ran the project - got another error.
    5. I started addressing the second error and in the process of fixing it I noticed that now VS is for some reason compiling an unknown external project whenever I run my project. I realized it because once the program hit the error and instead of jumping into my code and showing me the line, it showed me this message: "The source file is different from when the module was built. Would you like the debugger to use it anyway?" Also whenever I changed something in my code files now - the changes never apply. Moreover, the first error (which I have already fixed) resurfaced again, and when the debugger tried showing me the place of the error - it clearly used the new file, thinking that it's an old one (even if I change the new file to have empty space in the line where the error was, the debugger will still stand on that empty line, talking about the error).
    6. Now whenever I create a new VSX project, even an empty one, and compile/run it - the studio runs that unidentified external project (I have absolutely no clue where that project is, even the files that the debugger uses have no influence on that project.

    Wednesday, October 23, 2019 4:05 PM

All replies

  • That particular dialog is the debugger telling you that the ColoredRegions.dll that you are debugging (through the experimental instances of devenv.exe) doesn't match the current source file. 

    Basically, you're not debugging what you just built. It's most probable that you have an older version of the extension already deployed to the experimental instance, and for some unknown reason rebuilding your project is no longer updating/overwriting the earlier version of the extension.  If that's the case, you might be able to fix this by resetting the experimental instance, to remove the older/stuck version of the extension.

    Sincerely,



    Ed Dore

    Wednesday, October 23, 2019 5:35 PM
  • Hi cubrman,

    Welcome to the MSDN forum.

    Just as Ed Dore said, you have generate the old and conflicting version into VS local environment. And  this file ColoredRegions.dll is stored in the vs cache folder. So every time you create a similar vsix project, the file is read by default. Because the file is an older version, it results in different build types than the first version, so the old version is not overwritten whenever a new project is built.

    So you can delete the old version cache ColoredRegions.dll of this file just as the warning message prompts:

    "C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxxx\Extensions\xxxx\xxxx\xxxx\ColoredRegions.dll\

    >>you can also delete all vs cache files under C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxxx

    Hope it could help you.

    Best Regards,

    Perry


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com



    Thursday, October 24, 2019 8:02 AM
  • Thank you for your reply.


    I've reset the experimental VS by going to the start menu -> Reset Visual Studio 2019 Experimental Instance.

    I've also deleted the cache folders that you suggested.

    Now when I compile my project - a clean version of experimental Visual Studio starts - my code does not get attached to it. I know it for sure, because if I set a breakpoint in my code file, it shows an empty red circle and this message:



    Thursday, October 24, 2019 9:17 AM
  • Did you rebuild the project after resetting the experimental instance?

    Usually, I reset the experimental instance and run the experimental instance clean. Then I rebuild my extension, to copy/register it into the experimental instance. IF that doesn't fix it, can you post more details about your extension. How is it registered (what does the deployed .pkgdef look like, or what attributes you have on the package object that generates the .pkgdef)?

    The fact that a bp doesn't enable, doesn't mean your package didn't load. It could be that, but it could also be that the debugger could not find the .PDB that matches the assembly that was loaded. Use the Debug Modules toolwindow, to verify where your assmbly is being loaded from, and also check to see if the .PDB is missing.

    Hint you can right click on the module in the Debug Modules list to try and reload the PDB.

    If the module isn't listed, it hasn't been loaded. (indicating an issue with registering your extension).

    Sincerely,



    Ed Dore

    Thursday, October 24, 2019 5:54 PM
  • Ok that would be a lot of things I have no idea about :). Never went this deep into VSX development to understand half of what you wrote there. But I can google, and I can learn so here is what I did:

    1. I reset the experimental VS again and then cleaned and rebuilt my project.

    2. I ran the debugging session of my project and saw that now I can set a breakpoint (and it does not turn into an empty one).

    3. However, none of the breakpoints I set were hit once the experimental studio was launched. And overall my extension was clearly not working. Here I need to clarify something: I have a working extension project that worked under VS 2017. Now I am moving it to VS 19. The project that was created for VS 17 simply did not even launch under VS 19 (and the release version of the project did not want to install either), so I created a new extension project under VS19 and moved my existing files over.

    4. So at this point I need to provide you with more information. I will do it step by step, help me if I stumble. Here is what I think you are asking for:





    At this point the studio clearly does not attach my project code to the experimental version of the studio and I have no clue as to why.

    Thursday, October 24, 2019 7:28 PM
  • You have 2 different sorts of extensions here.

    1. A VsPackage, that registers a menu resource along with a custom Options page (per the attributes on your ColoredRegions2Package class. But that class doesn't appear to implement an InitializeAsync method (which is where you initialize your menu command handler).

    2. An editor extension that implements an IWpfTextViewCreationListener, for text based documents. If properly registered, I would expect a BP in that TextViewCreated method to be hit, whenever you opened a text file, .cs file, .vb file, etc.

    Make sure your .vsixmanifest lists both the VSPackage and MefComponent assets, otherwise the IDE won't see them.

    You might also want to try building a new VSPackage or Editor extension with the existing wizards, set a few breakpoints to verify you can debug that project, then cross check your existing project with the wizard generated one.

    Sincerely,


    Ed Dore

    Friday, October 25, 2019 7:33 PM
  • I've created an empty VSX Project from the template (remember, when I installed VS19 I ticked the box "extension development for Visual Studio"), reset the experimental studio, cleaned and rebuild the empty project, set a break point in it and pressed F5 - the studio launched without the project attached to it - the break points were white circles, like in the picture above. I am planning to reinstall VS, I hope traditional reinstall process will allow me to reinstall it cleanly without any debris left and I will let you know what happens once I reinstall it.
    Saturday, October 26, 2019 1:31 PM
  • An empty VSIX project is just an empty installer. There's no code to set breakpoints on. So I'm a little confused.

    I'm not sure a reinstall is really necessary. If you follow one of the VSSDK walkthroughs are you able to build and debug through one of those?

    Or better yet, just download and build one of the VSSDK Extensibility samples, the CustomCommand, or AsycToolwindow samples are good ones to start with.

    Sincerely,


    Ed Dore

    Tuesday, October 29, 2019 6:04 AM