Registering Custom Tool for File Generation

[JaedenRuiner]

Well,

I seriously have reviewed as many examples as possible for the installation of a Custom File Generator into the Visual Basic environment and thus far, I have not been able to get it to work. At the moment, my generator doesn't really do anything...Debugging and learning, you see, basically outputting some data, letting me know what happens the the Custom Tool is executed from within the VS IDE. As well as some exposure into the nature of the CodeDOM namespace. (not sure if i'm going to use that or not, but i'm investigating, learning, tis how i've learned every language I use.)

But here's the thing: Following all the steps and procedures, all the attributes and definitions, each time, everything says it's work, the Registry has all the appropriate information that it should have, but when I click "Run Custom Tool" the error comes back: "Cannot Find Custom Tool 'MyCustomTool' on this system."

Hrm.

Now, in the example they use a CodeGeneratorRegistration Attribute to handle the extraneous key additions into the Registry for the Visual Studio Custom Tool lists, currently, (since all that was written in C# and i didn't feel like porting it to VB myself) I'm just using the ComRegisterFunction() and ComUnRegisterFunction() attributes and handling the SOFTWARE\Microsoft\VisualStudio\{0}\Generators\{1}\{2} key/value additions myself (and they work so this shouldn't be an issue).
I Have Strongly Typed this Project with an SNK file as well, before compiling.

here is my class definition in VB, including all my imports so we know what namespaces i'm referencing:

      Imports System.Runtime.InteropServices 
      Imports System.Reflection 
      Imports VSOLE = Microsoft.VisualStudio.OLE.Interop 
      Imports Microsoft.VisualStudio.TextTemplating.VSHost 
      Imports Microsoft.Win32 
      Imports System.CodeDom 
      Imports System.CodeDom.Compiler 
      Imports Microsoft.CSharp 
      Imports Microsoft.VisualBasic 
      Imports Microsoft.VisualStudio 
      Imports Microsoft.VisualStudio.Shell 
      Imports EnvDTE 
      Imports EnvDTE80 
      Imports VSLangProj 
       
       
      Namespace Generators 
         ''' <summary> 
         ''' TODO: Documentation 
         ''' </summary> 
         ''' <remarks></remarks> 
         <ComVisible(True), _ 
          GuidAttribute("EB8B910F-CE35-46d6-B62C-930AB6C910FB"), _ 
          ProvideObject(GetType(FlufSettingsFileGenerator), _
RegisterUsing:=Microsoft.VisualStudio.Shell.RegistrationMethod.CodeBase)> _ 
          Public Class FlufSettingsFileGenerator 
            Inherits BaseCodeGeneratorWithSite 
      #Region "-------------::< Fields & Constants >::-------------" 
            Private Shared CSharpCategory As New Guid("{FAE04EC1-301F-11D3-BF4B-00C04F79EFBC}") 
            Private Shared VBCategory As New Guid("{164B10B9-B200-11D0-8C61-00A0C91E29D5}") 
            Private Shared CustomToolGuid As New Guid("{EB8B910F-CE35-46d6-B62C-930AB6C910FB}") 
            Private Shared VS2005Version As New Version(8, 0) 
            Private Shared VS2008Version As New Version(9, 0) 
            Private Const CustomToolName As String = "FlufSettingsFileGenerator" 
            Private Const CustomToolDescription As String = _
   "Generator that Creates A FlufApplicationSettings based MySettings Object" 
            Private Const KeyFormat As String = _
   "SOFTWARE\Microsoft\VisualStudio\{0}\Generators\{1}\{2}" 
      #End Region 
      #Region "-------------::< Public Methods >::-------------" 
            <ComRegisterFunction()> _ 
            Public Shared Sub RegisterClass(ByVal t As Type) 
               ' Register for both VS.NET 2005 & 2008 (C#)  
               Register(VS2005Version, CSharpCategory) 
               Register(VS2008Version, CSharpCategory) 
               ' Register for both VS.NET 2005 & 2008 (VB)  
               Register(VS2005Version, VBCategory) 
               Register(VS2008Version, VBCategory) 
            End Sub 
       
            <ComUnregisterFunction()> _ 
            Public Shared Sub UnregisterClass(ByVal t As Type) 
               ' Unregister for both VS.NET 2005 & 2008 (C#)  
               Unregister(VS2005Version, CSharpCategory) 
               Unregister(VS2008Version, CSharpCategory) 
               ' Unregister for both VS.NET 2005 & 2008 (VB)  
               Unregister(VS2005Version, VBCategory) 
               Unregister(VS2008Version, VBCategory) 
            End Sub 
      #End Region 
      #Region "-------------::< Protected Methods >::-------------" 
            Protected Shared Sub Register(ByVal vsVersion As Version, ByVal categoryGuid As Guid) 
               Using key As RegistryKey = Registry.LocalMachine.CreateSubKey( _
          String.Format(KeyFormat, vsVersion, categoryGuid.ToString("B"), CustomToolName)) 
                  key.SetValue("", CustomToolDescription) 
                  key.SetValue("CLSID", CustomToolGuid.ToString("B")) 
                  key.SetValue("GeneratesDesignTimeSource", 1) 
               End Using 
       
            End Sub 
       
            Protected Shared Sub Unregister(ByVal vsVersion As Version, ByVal categoryGuid As Guid) 
               Registry.LocalMachine.DeleteSubKey(String.Format(KeyFormat, vsVersion, _
                  categoryGuid.ToString("B"), CustomToolName), False) 
            End Sub 
      #End Region 
      End Class

Now, I didn't include the GenerateCode() override because that part is superfluous at the moment, since the error I'm receiving is the Custom Tool isn't on the system, not that the custom tool failed.

So, I set the configuration to Release (no pdb or xml output, just the DLL). I Go to the Directory:
C:\Source\Visual Studio 2008\External Tools
I run:
RegAsm /codebase SettingsGenerator.dll
GacUtil /i SettingsGenerator.dll

I close out VBExpress, reload it, go into my Settings.Settings item in the Solution Explorer and rename the Custom Tool to: FlufSettingsFileGenerator
I then try to "Run Custom Tool" And Get the aforementioned error.

Any Suggestions?

Thanks
Jaeden "Sifo Dyas" al'Raec Ruiner
Report post as abusive

 

[InteXX]

Hi Jaeden

Did you get this worked out? I'm having the same problem.

Let me know...

Thanks,
Jeff

 

[InteXX]

OK, got it. That didn't take long!

After reading this post, I suspected some sort of versioning issue.

I turned off automatic version incrementing in my code generator project by hard coding both the assembly and file versions to 1.0.0.1, rebuilding and restarting VS.

It worked, at least this time. Past performance, however, is no guarantee of future results. We'll just have to see.

Could that have been what you were running into?

 

[JaedenRuiner]

HOnestly, I have no idea.

I posted this a long time ago, and have pretty much reverted to using the MSDN forums. I don't normally get answers to my more complicated questions here (save for the critics telling me how to think like them instead of helping me resolve my issue). I vaguely remember this problem and I did resolve it, but I can't be sure if it was a Versioning issue, or if it was something even more pathetically idiotic on my part. As I recall during the creation of my file generators I had a lot of issues. Primarily, I was using the Express editions when I first started creating the generator and the Express editions are funky when it comes to Extensibility. (they aren't really designed to support it). however, I did end up hacking it to work with both express and pro editions, by doing a LOT of registry research. There are several locations in the registry that have to be set very specifically in order for the file generators to work correctly.

Additionally, be careful about hard coding the version, or at least be prepared to change it a lot. I wrote a little app that modifies the assemblyinfo.vb file for me to psuedo-auto increment the version. Before every build I can click an external tool icon to up the build/revision of the current project. This is due to the annoying design of Visual Studio, as it caches assemblies. (C:\Documents And Settings\%UserProfile%\Local Settings\Application Data\Microsoft\VisualStudio\9.0\ProjectAssemblies) WHen dealing with code generators (debugging them) or with forms components, the versioning is VERY important, because once you compile and use the item (whether it be a extensibility assembly or a component assembly) VS caches it and does not Re-Cache it upon change to the source, only change to the Version. So, while debugging you want to FREQUENTLY up at the minimum the build number (1.1.*.1 * = Build) so that VS knows "this is a new version of the assembly please re-cache it).

Hope this helps,

Jaeden "Sifo Dyas" al'Raec Ruiner

 

[InteXX]

save for the critics telling me how to think like them instead of helping me resolve my issue

Yes, there tends to be quite a bit of that over in the Linux camp:

"How do I configure this such-and-such?"

"Never mind that, you should be doing it the way I do it."
​

Yeesh.

be careful about hard coding the version, or at least be prepared to change it a lot

Yes, even considering the extra trouble, I think I'll keep it up. FWIW, the way I've been working it out while I debug the generator is to run it via another process (usually a quick-and-dirty WinForms app on the same solution) and write the resulting code out to a file within a different namespace. Then when I'm ready to go into 'production' I restart VS and all seems well.

VS caches it and does not Re-Cache it upon change to the source, only change to the Version

That's a good heads-up—I'll have to watch out for that. Thanks.