Comments

Gary James wrote on 1/8/2014, 7:59 PM
It doesn't seem possible. I've tried a few different ways without any luck.
NicoM wrote on 1/9/2014, 2:44 AM
I'm curious, what did you tried ?

I have these ideas:
- Use embedded manifest in the application extension, in order to tell the system, what .NET dependent assembly to load.

- Look for a way to host '.NET 4.5' code, from '.NET 2.0' compatible assembly.

Thanks
JohnnyRoy wrote on 1/9/2014, 9:35 AM
You cannot use .Net 4.5 until Sony Vegas Pro uses .NET 4.5.

Currently the version shipping with Vegas Pro 12.0 is Microsoft .NET Framework 3.51.

~jr
ChrisDolan (SCS) wrote on 4/24/2014, 9:34 AM
Vegas 13 now supports .NET 4.5 scripts and extensions.
Gary James wrote on 4/24/2014, 12:24 PM
Chris, so you're saying that Vegas Pro 13 was written using .Net v4.5, not v4.0?
ChrisDolan (SCS) wrote on 4/25/2014, 9:53 AM
Gary, you're right I should be more careful.

Vegas now launches the .NET 4 CLR internally, and all of our own C# DLLs (including the scripting API, the VP12 Explorer, the new Vegas Archive feature, XDCAM Explorer, etc) are compiled with .NET 4. We expect that any scripts and extensions that are compatible with the .NET 4 runtime should work inside Vegas.

In house, we're testing a fix to restore compatibility to .NET 2 and 3 extensions who are suffering from the LocalSource issue (.zipped extensions) and dependent DLL path issues (local policy problems). Expect to see those improvements very soon. This will get Timeline Tools and other popular extensions working as expected again.
Gary James wrote on 4/25/2014, 6:45 PM
Thanks for the update Chris. Even though people were at first telling me that Sony "intentionally" disabled old compiled Scripts and Extensions in SVP-13, that just didn't sound right to me. When I had some of the forum users try a few things, it became obvious that this was just an undesirable side effect of moving to .Net 4.0.

I'm sure you guys will knock this out quickly and move on to more important maintenance issues.

Thanks again for taking the time to respond personally.
ChrisDolan (SCS) wrote on 4/28/2014, 11:12 AM
Yeah, I will readily admit that the 4.0 upgrade did not go as smoothly as we expected. We thought it would be easy and staffed it as such. The beta testers were VERY VERY helpful in working out the initial kinks, but three significant bugs made it out the door, regretfully. Our next update (very soon! In QAs hands now) will hopefully put this all behind us.

The notes about intentional disabling was one of those game-of-telephone misunderstandings. There's a nugget of truth in it because we erroneously thought there were irreconcilable technical limitations of .NET 4 and we communicated that badly in the beta, but we never actually wanted to lose compatibility. And now I *think* we've regained 100% compatibility.