This was previously posted in dotnet.framework.interop, but no replies were
received.

Hello,

We've got a mixed mode application, which includes MFC/ATL and is written in
mainly C++ and some MC++. We are extending our product by calling assemblies
that have been written in C#. We've gotton through the hurdles of making
this work.

The issue comes up with trusted assemblies. Some of our users run our
application from a network share. In order to execute a .net application,
trust must be setup. Otherwise, an exception is thrown and the program
cannot be run.

Up to this point, we have had a digital signature, which is signed to the
mixed mode .exe in addition to each managed assembly (.dll). All is well,
accept we had to create an MSI which would add trust to our assemblies. It
then has to be run on each workstation. The MSI adds a new entry to the .NET
configuration tool (Control Panel->Administrative Tools) into the My
Computer->Runtime Security Policy->Machine->Code
Groups->All_Code->MyCompanyNameHere entry.

Although this is a pain, because the computers don't have admin rights, and
the MSI has to be run by an admin, and users don't have those rights.

This has worked, however we found out that the digital signature only lasts
one year. After that we have to resign the .exe and dll's AS well as create
a new MSI which must be run again on each workstation.

Is there a better way to do this, so that we don't need to go through the
hassles of resigning the code files as well as creating and executing (on
each workstation) the .MSI.

Many Thanks,

Paul

[quoted text, click to view]

Automation of the policy modification is also possible. For example, on a
Windows domain, the MSI can be installed from a GPO on a Windows domain. On
other network types, the are other options like using startup and/or login
scripts to execute a caspol command line.



[quoted text, click to view]

If you timestamp your signature (via the -t command line switch for
signcode.exe), you won't need to resign your assemblies when the signing
certificates expire. Obviously, you'll still have a problem with changing
signing certificates for patches and/or upgrades, but at least it won't be a
constant yearly problem.


[quoted text, click to view]

You could use only other criteria (e.g.: source URL) for creating your code
group, but I wouldn't recommend this. Using an publisher criterion is a
very good idea, and your best bet is probably to keep on doing so. In order
to minimize the work required, use timestamping and try to work with the
network admins to identify if there's some way the policy modification
distribution can be automated.