jaenicke - Mi 19.10.11 18:36
Titel: .NET DLL auf Netzlaufwerk - Aufruf von caspol.exe?

---

Hallo zusammen,

wir haben ein Problem mit den Sicherheitseinstellungen für .NET Assemblys, wenn das Programm auf einem Netzlaufwerk liegt.

Zunächst zum Umfeld:

• Ein Win32-Programm (in Delphi geschrieben)
  
• Eine ebenfalls in Delphi geschriebene Win32-DLL, auf die das Programm zugreift
  
• Eine in Prism geschriebene Assembly, die Funktionen für die Win32-DLL exportiert
  
• Eine System-DLL von Microsoft, die zur Hardwareansteuerung dient und von der Prism Assembly angesprochen wird

Lokal funktioniert das problemlos. Das ganze muss aber auch im Netzwerkverbund funktionieren, so dass das Programm über eine Netzwerkfreigabe gestartet wird. Für den UNC-Pfad kann ich dann die Sicherheitseinstellungen mit caspol.exe setzen:Wie geht das aber mit einem Netzlaufwerk?
Der Hintergrund ist, dass wir standardmäßig Laufwerk K: mit der gerade benutzten Netzwerkfreigabe verbinden.

Ich habe z.B. versucht:

• k:\*
  
• file://[IP]
  
• ...

Ich hoffe einmal jemand von euch kennt sich da besser aus und kann weiterhelfen. ;-)

Alternativ habe ich auch etwas zu .config Dateien gelesen und dass das darüber auch gehen soll, aber ich weiß jetzt nicht welche DLL ich da wie einbinden müsste... (deshalb die Übersicht oben)

Vielen Dank,
schönen Gruß,
Sebastian Jänicke

ujr - Mi 19.10.11 23:00

---

Hallo,

jaenicke hat folgendes geschrieben :

Ich habe z.B. versucht: k:\* file://[IP] ...

Laut http://blogs.msdn.com/b/shawnfa/archive/2004/12/30/344554.aspx sollte es "file://k:\" sein.

Könntet Ihr nicht auf Framework 3.5SP1 aktualisieren? Da sollte es die Probleme nicht mehr geben: http://blogs.msdn.com/b/vancem/archive/2008/08/13/net-framework-3-5-sp1-allows-managed-code-to-be-launched-from-a-network-share.aspx

Nette Alternative wäre ClickOnce-Deployment (native Dlls als Resource einbinden und bei Bedarf "entpacken").

jaenicke - Do 20.10.11 10:41

---

ujr hat folgendes geschrieben :

Laut http://blogs.msdn.com/b/shawnfa/archive/2004/12/30/344554.aspx sollte es "file://k:\" sein.

Leider nicht, ich habe es gerade ausprobiert.

ujr hat folgendes geschrieben :

Könntet Ihr nicht auf Framework 3.5SP1 aktualisieren? Da sollte es die Probleme nicht mehr geben: http://blogs.msdn.com/b/vancem/archive/2008/08/13/net-framework-3-5-sp1-allows-managed-code-to-be-launched-from-a-network-share.aspx

Die hardwareseitig ausgelieferten DLLs von Microsoft POS for .NET sind für .NET 2.0, so dass das nicht möglich sein wird.

ujr hat folgendes geschrieben :

Nette Alternative wäre ClickOnce-Deployment (native Dlls als Resource einbinden und bei Bedarf "entpacken").

Die nativen DLLs sind ja nicht das Problem, sondern die von dort aufgerufenen .NET DLLs. Beim Versuch das zu tun kommt eine externe Exception, eben wegen der fehlenden Zugriffsrechte.

ujr - Do 20.10.11 11:03

---

jaenicke hat folgendes geschrieben :

ujr hat folgendes geschrieben : Laut http://blogs.msdn.com/b/shawnfa/archive/2004/12/30/344554.aspx sollte es "file://k:\" sein. Leider nicht, ich habe es gerade ausprobiert.

Mit '*'? Schade.

jaenicke hat folgendes geschrieben :

ujr hat folgendes geschrieben : Die hardwareseitig ausgelieferten DLLs von Microsoft POS for .NET sind für .NET 2.0, so dass das nicht möglich sein wird.

Das ist doch kompatibel?!

jaenicke hat folgendes geschrieben :

ujr hat folgendes geschrieben : Nette Alternative wäre ClickOnce-Deployment (native Dlls als Resource einbinden und bei Bedarf "entpacken"). Die nativen DLLs sind ja nicht das Problem, sondern die von dort aufgerufenen .NET DLLs. Beim Versuch das zu tun kommt eine externe Exception, eben wegen der fehlenden Zugriffsrechte.

Es ginge ja darum, dass der Networkshare immer die aktuelle Version zur Verfügung stellt, die dann (lokal) entpackt bzw. installiert wird. Dann müssen die nativen Dlls natürlich hinzugefügt werden. Allerdings hatte ich nicht berücksichtigt, dass das eigentliche Programm eine native Anwendung ist. Da weiß ich nicht, wie sich das verhält.

Ralf Jansen - Do 20.10.11 11:07

---

Zitat:

Die hardwareseitig ausgelieferten DLLs von Microsoft POS for .NET sind für .NET 2.0, so dass das nicht möglich sein wird.

Vermutlich doch. Ich denke die entscheidenden Bits stecken in 2.0 SP2 das zusammen mit 3.5 SP1 ausgeliefert wird und nicht in den speziellen 3er oder 3.5er Teilen.

jaenicke - Do 20.10.11 16:52

---

Ja, so ist es in der Tat, mit dem 3.5 SP1 geht es! :dance2:

Danke euch! :zustimm: