Comments

jetdv wrote on 5/12/2022, 4:52 PM

@robert-bogue, see if this tutorial will help you:

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

robert-bogue wrote on 5/13/2022, 6:52 AM

@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 wrote on 5/13/2022, 8:24 AM

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.

robert-bogue wrote on 5/13/2022, 8:48 AM

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

jetdv wrote on 5/13/2022, 9:04 AM

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