I found some posts on this forum about this same problem. Trying to run an AddIn from a network drive in the local network runs in to SecurityExceptions. I specifically found some posts where someone was sneering at Microsoft for having a bad security policy.
As test I wrote a dll with 1 Shared Sub and placed it on the exact same network location. In this Sub I demand FullTrust for calling the Sub and I make a call to Process.Start("Notepad") which also requires Full Trust. I then wrote an exe which I ran from the local harddisk. This program loads the dll as an Assembly by calling Assemly.LoadFile([dll-location]). Then using Reflection I call the Sub. This runs flawlessly, Notepad opens.
The test shows me that my network location is trusted by my .NET configuration, but when I'm running MicroStation it's suddenly not trusted. As long as I'm not missing a very obvious thing, to me this shows that it's Bentley that made an error, and not Microsoft. Is there a solution for this by now, as the posts i found were 3 and 5 years old. Or will this be fixed with the new .NET API in the next version?
--edit--
This question has 2 answers. Jan gives the right answer out of the box. Robert gives the solution with a little unsupported modification of the config.
Hi,
I am pretty sure it's a standard NET behaviour, not bug in MicroStation. If you will search for this topic on Internet, you will find plenty of similar discussions without any relevance to MicroStation.
From one such discussion I remember it's solved in NET 4. And because we can suppose the next generation of MicroStation will be based on NET 4 (at least), it will be solved automatically.
WIth regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Answer Verified By: MVlaardingerbroek
And there's my obvious thing I missed.
I built the dll in FrameWork 3.5 as MicroStation doesn't accept 4 and higher. The exe was 4.5 as I forgot it the second time. Recompiling the exe in 3.5 throws a SecurityException. Guess I have another reason for wanting the next version.
Unknown said:Trying to run an AddIn from a network drive in the local network runs in to SecurityExceptions
That's normal Windows behaviour.
Regards, Jon Summers LA Solutions
Well, as Jan stated it's fixed in .NET Framework 4 and higher. Which is also proven by my test. So normal Windows behaviour is that it works. Bentley just has to update their .NET code which is a few years behind.
The version is 08.11.09.292.
I made it so that MS_ADDINPATH = $(MS_MDLAPPS). My less technical coworkers had some trouble understanding the difference between .dll and .ma, so I made it that they can throw both in the same path and it still works.
I also added a MS_ADDINPATH > C:/[some local dir] to work around the SecurityExceptions. Shame I now have to distribute the .dll to all microstation computers. Kinda defeats the central location of the WorkSpace.
to set MS_ADDINPATH is not sufficient, because it has no higher priority than NET framework security policy.
Unknown said:Shame I now have to distribute the .dll to all microstation computers. Kinda defeats the central location of the WorkSpace.
You can use caspol.exe utility (delivered with Windows) to assign Full Trust to network shared location, which should help to solve the problem. Sorry I don't advice the exact command, to research correct way how to setup it is something on my to-do list for a long time :-( But there are descriptions available on Internet valid for other NET based applications.
With regards,
I know about caspol.exe. I'm still debating whether I'm going to make a login script that includes caspol.exe or where I just copy the dll to a local folder.
1 reason I won't do caspol: it only works for the framework version it got distributed with, and i really don't feel like getting it for all versions and finding out which version Bentley has incorporated into MicroStation.
My AddIns are running from a network share using .NET 4 and caspol ;-). If You're interested though, this is the way:
1. Compile Addins for .NET 4
2. Local PC: Configure Microstation to use .NET 4 (not supported, but works for me so far) via ustation.exe.config:
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/></startup><runtime> <!-- Original stuff here --> <!-- .NET 4 AddIns: Load assemblies using CAS policies --> <NetFx40_LegacySecurityPolicy enabled="true"/></runtime>
3. Local PC: Setup CAS policies for .NET 4 (CasPol.exe -m -cg 1.2 FullTrust)
May be there's a better way to manage security concerns, since CAS policies are not the preferred way in .NET 4.
Robert, I tried your solution, but i skipped the legacysecuritypolicy. That's exactly what makes CAS needed. It runs happily, and as our self written AddIn is the only thing we're loading into MicroStation that's .NET I'm not too worried this will break other stuff. We'll monitor it for a while, but it now runs from network, without caspol and without lowering pc security settings.
I marked both Jan and Robert as solution. Because Jans answer is true when not hacking, but Roberts answer works with a little unsupported modification of MicroStation.
Unknown said:skipped the legacysecuritypolicy. That's exactly what makes CAS needed
Yes, but whithout this Microstation doesn't load one of my AddIns because it "has no authorized digital signature". What have You done that Your AddIn runs whithout CAS?
Nothing special as far as I can remember. I didn't want to mess around with the full AddIn as I didn't want to break it while trying to make it run in V4.0 so I wrote a tiny test project. All it does is inherit from AddIn, contain a constructor and overrides the Run method. In both the constructor and the Run method I have a call to MsgBox so I can see it's working. The full code is 15 lines, including the white lines for readability. Oh, and commands.xml of course.
I was planning to change the full AddIn later, haven't gotten to that yet, too much other work.
In which Framework version did you compile the AddIn that refuses?