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.
https://communities.bentley.com/products/microstation/w/microstation__wiki/15724/utility-cannot-be-loaded-because-its-not-digitally-signed
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?
JD
Hi John,
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.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan,
its written in 4.6.2 framework
I don't disagree with what your saying, that's where I was looking (CAS). but something on this user's side changed when going to windows 10 don't know what.
but I just got another user (different company) that's running windows 10 that's getting the same error.
Could the .dll be Blocked?
I have this happen sometimes when sending .dll files to a client. Downloading from an ftp site, google drive, dropbox, etc. the .dll can get blocked by Windows security. Have them check the file properties and click Unblock if the option is there.
Rod WingSenior Systems Analyst
had the user check, and this is not the problem.