Hoping someone can help me with this problem.
I made a c# wpf addin for MicroStation, its a dll. I can load it fine on my end. but i have sent this to someone else and when they try and load it they get error message that says 'OHDOTSHEETMANAGER' is not trusted. OHDOTSHEETMANAGER is the name of the app.
then in the Message Details it says this...
'OHDOTSHEETMANAGER' could not be loaded because 'OHDOTSHEETMANAGER' does not have an authorized digital signature.
i found this post.
but i checked and the user has MS_SECURITY = NONE.
so i shouldn't need to have it have an authorized digital signature.
anyone run into this before? i works fine on my computer, are there additional things within MicroStation that control this?
Are they running it in vanilla MicroStation or in something like OpenRoads Designer?Products other than vanilla MicroStation can require a special password that you have to request from Bentley.... Though I am not sure that the error would be "Does not have an authorized digital signature" for this case
its in OpenRoads Designer
John Drsek said:I made a c# wpf addin for MicroStation, its a dll. I can load it fine on my end. but i have sent this to someone else and when they try and load it they get error message that says 'OHDOTSHEETMANAGER' is not trusted
That looks like a Windows error message to me. Where, on the client computer, is your DLL installed: local to that machine or on a network server?
When you build your apps., do you sign them with a digital signature in Viz Studio?
Regards, Jon Summers LA Solutions
i don't typically, but i did sign the assembly with a strong name key but that didn't solve the problem.
for a dll the Sign the clickonce manifests is not enabled.
should i be doing something else?
John Drsek said:should i be doing something else?
Where, on the client computer, is your DLL installed: local to that machine or on a network server? Windows may be objecting if MicroStation is attempting to load the DLL from a network drive.
there on a network drive, but thats the desired location . I'm able to run them off a network drive.
John Drsek said:there on a network drive, but thats the desired location . I'm able to run them off a network drive
There may be an IT policy difference between your network and their network. It looks like a Windows issue rather than a MicroStation problem. To test, tell your client to install the DLL on a local drive (in the MS_MDLAPPS) folder.
will do..im thinking it will work on the local drive..now just need to figure out what policy setting to blocking this..thinking there should be something to add like a trusted path or something
so it worked on the c drive like i thought it would.
he was running everything on windows 7. had him try it in windows 10 and it worked. so gonna leave it at the solution is it upgrade to windows 10 since windows 7 losses support in January.
you did not write what NET version do you target in your application, but I assume it's something like 4.6.x.
How remote assemblies are loaded and what security policy is applied differ in different NET versions, but in general in NET 3.5 CAS policy (code access security) was applied by default, which means remote assemblies were treated as not fully trusted and were loaded accordingly to assigned zones. From NET 4 this policy is switched off by default, so you should be able to load remote assemblies (from network) without any problem.
What policy is applied can be configured at different places, so it's hard to say what is a source of the discussed behaviour and what is the simplest solution, but as discussed already, IT staff should be able to say whether e.g. CAS policy is configured at company / domain level.
In my opinion there is no difference between Windows 7 and Windows 10, because the policy is applied at NET runtime level, not Windows.
Labyrinth Technology | dev.notes() | cad.point