I'm developing an extension for Vegas -- which I've done before.-- but for some reason Vegas isn't loading the extension. Is there a way to see a log of what problems Vegas is encountering at startup? Or is there a way to enable diagnostics for the script portal?
One thing you can do is throughout the startup process you could either write your own log or just throw up a series of message boxes and note the ones that appear. The issue will be between the last one that appears and the first one that doesn't...
@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.
@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=18.104.22.168, Culture=neutral, PublicKeyToken=3cda94b1926e6fbc, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "log4net, Version=22.214.171.124, 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=126.96.36.199, Culture=neutral, PublicKeyToken=3cda94b1926e6fbc, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "ScriptPortal.MediaSoftware.clrshared, Version=188.8.131.525, 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.
@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:
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.
Thanks. I ended up having to run ProcMon to see the issue. with known folder redirects you must target the redirected location not the location provided above. Also, it appears that the %AppData%\..\Local\Vegas\Application Extensions path is no longer supported (at least in 19).