Hi folks,

A winforms app at a client's site, has started crashing on startup with this dialog:

(AppName) has encountered a problem and needs to close. We are sorry for the inconvenience.
If you were in the middle of something, the information you were working on might be lost.

Aside: I haven't yet been to the client site (45 mins drive away) to investigate further, so there is a bit of speculation here, but I think it best to be prepared since I might need answers quickly...

Because this is a standard XP exception dialog, and not an mmExceptionForm, the error must, I deduce, be happening before the TRY..CATCH in the AppMainEntry.Main() method.

The only way I can reproduce this error - by deliberate sabotage or any other means - is by running the exe/*.dll from a network share. The system then crashes with a System.Security.SecurityException "That assembly does not allow partially trusted callers"

Obviously there may be other reasons (not that I can think of any that make sense!) for crashing and I will be verifying this, but this is worth investigating.

OK, the reason for the Security Exception being thrown is presumably because the .NET framework is regarding the EXE/DLL as less than fully trusted, and the MM.NET DLLS are strong-named without the AllowPartiallyTrustedCallers attribute (APTCA)

The puzzling thing is, the app was working before the "latest update" - which simply meant coping the new exe/dll files on top of the old ones, in a folder on the C: drive. No setup project was used. The client tells me when they copy the previous version back, same symptoms. This should be in the "My Computer" zone and thus trust issues aren't a problem.

So ...
(a) Anyone have any ideas why files on the C: drive should be regarded as less-trusted .. except for someone expressly manipulating a policy of course.
(b) Will using a setup project automagically solve this issue (the install program setting up the appropriate code access policy etc)?
(c) Would strong-naming the application components do anything useful? (I can't see why, it doesn't solve any trust issues)

Recompiling the MM.NET assemblies with APTCA, although it would fix this particular problem, strikes me as a bad idea. Well, it's certainly ducking the problem anyway.

My best bet so far is that the overlords of IT have locked down the computers somehow, and that this lockdown has occurred coincidentally with the update. Seems a bit far-fetched. I've done copy-style deployments of MM.NET apps elsewhere, hang it, THIS one was working previously.

So.. HEELLPP!! Any ideas?
----------------
By the way, to help diagnose this error I've added a small wrapper to the app in Main.cs. Might be useful to some people.

public class AppMainEntry : mmMainEntry
{
...
    public static void AppMain()  // renamed from Main(
    {
...
public class AppMainWrapper
{
  [STAThread]
  public static void Main()
  {
     try { AppMainEntry.AppMain(); }
     catch (Exception e)
     { MessageBox.Show(e.ToString()); }
  }
}