post v13 upgrade issues

Jan 22 at 7:37 PM
Edited Jan 23 at 1:31 AM
Just upgraded to v13 and am getting the following error in vs 2010

Error 3 Unable to load the metadata for assembly 'VMS.TPS.Common.Model.API'. This assembly may have been downloaded from the web. See The following error was encountered during load: Could not load file or assembly 'VMS.TPS.Common.Model.API, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

to upgrade the script, I removed the prior Model.API reference and added a reference to the same DLL from C:\Program Files (x86)\Varian\Vision\13.7\Bin64\esapi.

There is no unblock on the properties

I did not see this prior to v11. Do i need to do more to update any particular script? it builds fine, but when I go to look at a window the error message comes up.
Jan 23 at 8:27 PM
So it seems my issue is limited XAML and the designer. I remember not having intellisense in XAML w/11, but I could still work in the designer when using types from VMS apis. Now, the designer does not function at all if there is a VMS type anywhere in the XAML. Any ideas? I hate to think this is what I've got going forward. Im using VS 2010
Jan 24 at 8:19 PM
Do you get any warnings when you compile?

Can you run your script inside Visual Studio? If so, go to Exception Settings (Debug -> Windows -> Exception Settings) and turn on all "Common Language Runtime Exceptions" and try to make your script throw the exception from above. It may give you more information (but it may not).

You can also try to Debug Assembly Loading in Eclipse with Fuslogvw.exe.

Another thing to try to to make sure you're referencing the same .NET version as the Varian DLLs.
Jan 25 at 12:24 AM
Looks like the tool you referenced sees the problem, but I dont know how to fix it. Below is a snippet of the log...

=== Pre-bind state information ===
LOG: DisplayName = Aria_DataAccess, Version=, Culture=neutral, PublicKeyToken=null
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL

Calling assembly : (Unknown).

LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/Aria_DataAccess.DLL.

LOG: All probing URLs attempted and failed.

I keep everything on a USB drive. Do I need to set some path in dev env somewhere?

Thanks for all the help so far
Jan 25 at 1:34 PM
Edited Jan 25 at 1:47 PM
I dont think that last post is indicative of the core problem. Ive fiddled with a lot of stuff try and fix it and one thing has been Any CPU/x64. I think the above post has more to do with some project in the solution being the wrong architure accidentally.

Eveything is set to Any CPU now. Gonna reboot and test...
Jan 25 at 10:11 PM
Downloaded vs 2012 express to test and I get...

Design view is unavailable for x64 and ARM target platforms.
Jan 25 at 10:21 PM
In v13.7 Can anyone else declare the VMS.TPS.Common.Model.API namesspace in XAML, i.e. use the line

xmlns:varian="clr-namespace:VMS.TPS.Common.Model.API;assembly=VMS.TPS.Common.Model.API" and then create a datatemplate resource for a VMS type?

Im giving up and building a layer between VMS... and my front end.

Goodbye to binding to VMS,, hello to encapsulation (and to bitterness towards 13 for having to do this).
Jan 31 at 11:14 PM
I actually have all my projects set to x64. Otherwise, I get warnings about incompatibilities with the ESAPI DLLs.

Is there any reason you need to use VS 2012? VS 2015 Community is free and, so far, I haven't had any problems with ESAPI v. 13.6.

I think encapsulation is the way to go. If there's ever the chance that you will want to run the GUI thread separate from the VMS thread, you could run into problems. Also, it will be easier to unit test your classes if they don't return VMS types directly (except perhaps the struct types, like DoseValue). I've found that some unit testing frameworks run the tests on a separate thread, causing crashes when they try to access VMS types directly.
Feb 1 at 8:01 PM
Edited Feb 3 at 2:17 PM
I don't know enough about programming and am afraid, if i have the most up to date VS, Ill end up using something in a development environment that's not available on a general hospital computer. Most of my lil' programs are non-ESAPI/DICOM/DB based stuff. An older VS is a (perhaps misguided) attempt to protect myself from my own ignorance. I was using 2010 until this upgrade gave me so much trouble. thought 2012 might fix it. If it weren't for the DataGrid, i'd still be in .net 3.5 :)

Thanks for the advice on encapsulation and threading.