different ACL for an assembly if launched from windows explorer or from command prompt?? (Why is the security context different?) RRS feed

  • General discussion

  • We have a windows form application that is deployed to several remote users.

    We use a batch file to execute the application.
    This batch file is in charge of doing an xcopy of any new files sitting on the deployment share (Intranet).

    The batch file also starts the application.

    We've noticed since a week ago the application is behaving differently if it is called from the batch file or from the command prompt than if the application is called from windows explorer.

    The actual error is in loading some objects from our domain model, the objects are not instantiated properly when we run the application using the following line on our batch file

    start applicationname.exe

    The same application works without problems (objects are instantiated and do not give null reference errors) when we double click the executable in windows explorer or use the following line in the batch file

    explorer applicationname.exe

    Any comments or suggestions for troubleshooting this are more than welcome.

    Why is the security context different?


    • Changed type Bruno Yu Friday, June 20, 2008 5:00 AM Change the unreplied thread to Comment.
    Friday, June 13, 2008 8:41 PM

All replies

  • Lizet,

    Based on your post, the behavior is different by calling from batch/command prompt and windows explorer caused by not instantiated properly when loading objects from domain model. This is all the information I can get from your post. For the security context issue, you can read the article An Overview of Security in the .NET Framework

    How is your problem going? Is there any progress or more related information you can provide to find out the problem? Thanks for your question and waiting for the reply.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Tuesday, June 17, 2008 8:34 AM
  • We are changing the issue type to “Comment” because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to “Question” by editing your initial post and changing the radio button at the top of the post editor window. If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.

    Thank you!

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, June 20, 2008 5:01 AM
  • Bruno,

    I hope is not too late. Unfortunately due to a constraint on another layer in the application (sql server merge replication) we had to make all the users administrators of the PCs where the c# application runs.


    This solved us two problems.

    I do know that elevation of privileges is not the best solution always, but the merge replication part is staying for a while and it does have the constraint that in order to launch the merge agent at the distributor and create local databases and subscriptions the user logged into the sql server engine should be a dbo. These sql engines only have windows authentication, not sql server mixed authentication so these users belong to the machine administration group.






    Thursday, July 29, 2010 9:54 PM