@jetdv - I'm relatively certain that Vegas is having a problem loading the DLL since the menu options aren't getting registered. It's not that the code is up and running so I can insert statements in it -- it's that there's a problem in the load sequence -- thus wanting Vegas to generate logs. .NET is sometimes peculiar about bindings and that's probably where I need to start.

You may still need to write your own log during the initialization process. But have you tried debugging as explained in the video I linked to?

Or, you could start over with a known good base and then just add your functionality back in:

Getting started video with link to the base code:

Changing the items that need to be changed in the base code:

Or just download the base code and compare it to what you are using.

@jetdv - Sorry, you don't understand. When Vegas tries to load the DLL it goes through a process in .NET which tries to load the assembly as well as dependent assemblies. It's possible for the calling program (Vegas) to log the process that the framework goes through to locate the dependencies -- and identify mismatches between the versions in use by the DLL and the framework as loaded. For instance, if they're running v.4.72 of the framework and I'm compiled against v.4.70 there's a set of translations that are loaded automatically. -- in some cases, like I'm compiled against 4.8 instead of 4.72 it may not be possible to load the assembly. Given there's no information about what the framework in use is -- it's hard to target. More than that, as a technical matter the framework is supposed to load dependent assemblies from both the GAC and the current directory -- but this behavior can be overridden. Again, without the fusion log or documentation there's no way to tell what's breaking.

Simple things without any dependencies load fine -- and I've done that. However, code which has dependencies don't seem to load well. For what I'm doing I don't want to have to copy/replicate code that is better managed in a dependent library.

Again, I've developed extensions before. I've just lived with the limitation of not having dependent assemblies. I don't want to do that this time.

@robert-bogue, I just did some testing on this the other day. If you look at the comments on this tutorial:

This was all testing using a compiled script (not a custom command) but the results may apply:

VEGAS Pro 14 - .NET 4.0 works fine

VEGAS Pro 15 - .NET 4.0 works fine

VEGAS Pro 16 - .NET 4.0 works fine

VEGAS Pro 17 - .NET 4.0 works fine

VEGAS Pro 18 - .NET 4.0 works fine

VEGAS Pro 19 - .NET 4.8 needed

VEGAS Pro 14 set to .NET 4.8 - works fine

So set to .NET 4.0 using the VEGAS Pro 19 DLL as the base, you will get these error messages:

The primary reference "ScriptPortal.Vegas, Version=14.0.0.134, Culture=neutral, PublicKeyToken=3cda94b1926e6fbc, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "log4net, Version=2.0.12.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".         

The primary reference "ScriptPortal.Vegas, Version=14.0.0.134, Culture=neutral, PublicKeyToken=3cda94b1926e6fbc, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "ScriptPortal.MediaSoftware.clrshared, Version=19.0.0.615, Culture=neutral, PublicKeyToken=3cda94b1926e6fbc" which was built against the ".NETFramework,Version=v4.8" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".

Interestingly, the DLLs compiled against VEGAS Pro 14 using .NET 4.0 also work fine in VEGAS Pro 19.

Excalibur is compiled against the VEGAS Pro 14 DLL using .NET 4.0 and it loads fine in VEGAS Pro 19.

@jetdv - Is anyone from MAGIX even watching these forums? It seems like a simple request to get more details about how to get those fusion logs would be helpful.

@robert-bogue The "fusion log" is a Microsoft tool. It runs independent of VEGAS. Look through the .NET SDK documentation for more information.

@VEGASNeal1 - That's not exactly true. I'm trying to find out why Vegas isn't loading my extension -- FUSION is the part of the process that loads assemblies. It's possible for any caller to get this log to understand why a DLL did or didn't load. If you prefer I restructure my question, How do I get a log of what extensions that Vegas tried to load and what errors it encountered? In this case it's a loading error -- either because it can't resolve underlying DLLs or because of framework mismatches. How do I figure out what it's issue is?

@robert-bogue first, verify the extension module assembly DLL is placed in one of the documented locations which VEGAS scans for extensions, such as "C:\Users\(username)\Documents\VEGAS Application Extensions". Any dependent assemblies you've created can be placed there as well.

For VEGAS to load the extension module assembly, the requred entry points must be present and the extension must specify where in the VEGAS menu system the extension will appear.

VEGAS performs no other load actions, all dependent assemblies are loaded by .NET automatically.

If the menu item for your extension does not appear, or the extension does not run when the menu is activated, then yes, either the extension is encountering an exception, or a dependent assembly cannot be located.

You can check for exceptions by attaching the Visual Studio debugger and monitoring activity as VEGAS loads your extension module assembly DLL.

Microsoft's Fusion Log Viewer (fusionlogvw) is also a useful tool to track problems loading dependent assemblies. Refer to this URL for instructions on its use:

https://docs.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer

As an example, here is the log of a load failure of a prototype Text-to-Speech extension where I specifically removed one of the dependent assembly DLLs. The extension module loads, the menu item is seen within VEGAS, but the extension fails to launch when the menu item is activated due to the missing DLL.

The log shows that an assembly of the correct name is loaded, but the version does not match the one needed by the extension. Different versions happen to exist because Text-to-Speech is now part of the VEGAS application proper, the old prototype extension cannot be used with the more current assembies that install as part of VEGAS.