Click here to Skip to main content
Click here to Skip to main content
Go to top

Using MSI or a strong name to store .NET apps on a network server (Part 1)

, 31 May 2005
Rate this:
Please Sign up or sign in to vote.
Using MSI or a strong name to store .NET apps on a network server (Part 1).

Sample Image - Using_MSI_or_a_strong_nam.jpg

Introduction

Before .NET, my company had several network servers that were used as a place to store applications. If you wanted to use one of these apps you had to have a mapped drive to the network server. Then you could launch the app from there. So the EXE was stored on the network, but the app would still run locally when launched. We used Delphi so there was only the EXE, no DLLs to install, register etc. Now with .NET, the Windows apps have to be installed locally for them to be fully trusted. There are several publications that list all of the things that are not trusted from an application that is not installed locally. Some examples are, no file IO, no access to registry, no access to database stuff, the list goes on. Installing an application locally is a pain especially when it comes to releasing a new version. It needs to be released to everyone who has already installed it. It is a lot nicer just to release it to one spot on the network. Of course, you do have to make sure no one is using the app when you release it to the network. Or you have to bounce them out of the app. Still you only have to release it to one place.

Background

So there are options in .NET for distributing applications. If you have a local intranet you can host an ASP.NET application. This can be somewhat limiting for extremely complex applications that are better suited for a Windows style application. It is not always easy to release something new on the web either even if it is your local intranet. You can use a web server to help distribute the application. Something like: it checks to see what version you have locally and if there is a newer version it is installed locally and then launched. You can use terminal server. The application only exists on the terminal server and your users have to log into the terminal server to access the app. We have tried all these approaches and personally I don't care much for them. So on to the next two. First, the one I like best, create a machine level runtime security policy. Then put it into a MSI script and have your users run the MSI script (they only have to once), or have Active Directory distribute the MSI script at login. This policy marks a network server and folder on that server as fully trusted. The other option is to use the SN.exe tool to create a strong name key and mark all of your applications with the strong name key and then create a runtime security policy allowing anything with that strong name key to be fully trusted. In part 1 of this article, I will only be reviewing how to do the machine level runtime security policy that marks a network folder as fully trusted.

How do you do it...

First, let me show you the error you get if you try to launch a .NET app from the network when it is not fully trusted.

Security Error

Next, I will describe how to do the run time security policy that marks a network server and folder as fully trusted. This is something we are currently doing and it seems to be working well. You set up a machine level runtime security policy in the .NET framework configuration tool, which can be found in Control Panel->Administration tools. Note that if you are not an Administrator on your PC, you will not be able to set a runtime security policy. Under Runtime Security Policy\Machine\Code groups\All code\localIntranet_zone\, you want to add a child code group.

Creating a child code group

Put in a name and comment for the new code group and click next.

Select URL and enter the URL

Now you need to select the URL from the drop down and put the servername\foldername in the URL textbox. It should follow this format: file://SERVER/Folder/*. Then click Next.

Select full trust

Next you need to select what security you want this folder to have. Full trust is what I usually pick, but there are several options. Then click Next and finally click Finish. At this point you would be able to launch a .NET Windows app from the server\folder you just set up in a code group and you would not get a security violation.

Creating the MSI script

On to creating the MSI script for this code group. Click on the runtime security policy. You should see an option for creating a deployment package. Click that option.

Creating MSI

Next you should select the machine on the radio group and put in a local path and name for the MSI script.

Select machine level

Click Next and click Finish.

Conclusion

Now you have an MSI script that people can run, they only have to do it once, and they will be able to launch a Windows .NET app from a network server and they will not get a security violation. Note, when the MSI script is run, it will replace any current runtime security policies on the machine level. You can distribute the MSI script over Active Directory, but I will not include that in this article. In part 2 of this article, I will discuss how to do something very similar to what we did in this article except we will be using a strong name key instead of a URL to grant full trust rights to an application.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

kubben
Web Developer
United States United States
I started my programmer career over 18 years ago doing COBOL and SAS on a MVS mainframe. It didn't take long for me to move into windows programming. I started my windows programming in Delphi (Pascal) with a Microsoft SQL server back end. I started working with vb.net when the beta 2 came out in 2001. After spending most of my programming life as a windows programmer I started to check out asp.net in 2004. I achieved my MCSD.net in April 2005. I have done a lot of MS SQL database stuff. I have a lot of experience with Window Service and Web services as well. I spent three years as a consultant programing in C#. I really enjoyed it and found the switch between vb.net and C# to be mostly syntax. In my current position I am programming in both vb.net and C#. Lately I have been using VS2012 and writing a Windows 8 app. You can search for the app it is called ConvertIT.
 
On a personal note I am a born again Christian, if anyone has any questions about what it means to have a right relationship with God or if you have questions about who Jesus Christ is, send me an e-mail. ben.kubicek[at]netzero[dot]com You need to replace the [at] with @ and [dot] with . for the email to work. My relationship with God gives purpose and meaning to my life.

Comments and Discussions

 
GeneralYou can automate the whole process Pinmembergiridhar7531-Oct-05 20:50 
GeneralRe: You can automate the whole process Pinmemberkubben1-Nov-05 2:21 
QuestionWhere should you save your Dev work? Pinmemberkubben14-Jun-05 3:06 
Generalgood column but... Pinmembercarlopagliei12-Jun-05 21:25 
GeneralRe: good column but... Pinmemberkubben13-Jun-05 3:04 
GeneralRe: good column but... Pinmembercarlopagliei13-Jun-05 3:25 
GeneralSounds painful... PinmemberRobola11-Jun-05 11:21 
GeneralRe: Sounds painful... Pinmemberkubben12-Jun-05 2:19 
First, we go through the trouble of creating a MSI package once. It gets distributed once and then the user is set. Not all users will have database access to apps that we release. So automatcally creating a shortcut is not something we want. It sounds like the size of your company is about 7 times that of mine, so perhaps different solutions for different sizes of companys.
 
Actually this solution doesn't require a mapped drive. The user just needs access to the UNC path. Some users still chose to map a drive since that is what they used to do. Still all they have to do is create a short cut (or have helpdesk help them) with the unc mapping the program or go to start run and pick it from the list (if they have typed it once).
 
You have some valid points although depending on your network bandwidth and the number of people you will be sending the msi script to, the size of the MSI script, you could be looking at an all day event to get it out. Our network is pretty spread out with several remote facilities (six different states).
 
On another subject, the release coordinators we have are not admins of the network and have no programming skills. They like to be able to control release and roll back of applications. So in your suggestion the msi gets rolled out to everyone's pc, now they got the new version. Oops something is wrong time to roll back. Time to send out the previous msi script to put the old app back. Doesn't sound too fun to me. That type of stuff shouldn't happen, but it does.
 
Finally, I may be a young programmer, but it still doesn't sound like a real good idea to just turn off the share when you want people to get out of your apps. I certainly wouldn't want that to happen to me while I was in the middle of doing my every day job. You can bet that would cause the help desk phones to light up. You can imagine the phone calls. "What the @#@ just happend to my program?", help desk - "Oh you know, the @# programmers just released a new version."
 
Of course, if the app you just released is used by any management it could be worse...
 
So bottom line. I agree with your general argument that active directory should be used more. Still, am I ready to suggest an architecture that all .net windows apps are distributed through it? No, I prefer something that allows the release coordinators to have easy control over getting apps out. They know the app is in one place and that is all they have to worry about.
 
Sincerely,
 
Ben
GeneralRe: Sounds painful... PinmemberRobola13-Jun-05 4:21 
GeneralRe: Sounds painful... Pinmemberkubben13-Jun-05 4:37 
GeneralRe: Sounds painful...One more thing Pinmemberkubben12-Jun-05 2:48 
GeneralRe: Sounds painful...One more thing PinmemberRobola13-Jun-05 4:40 
GeneralRe: Sounds painful...One more thing Pinmemberkubben13-Jun-05 7:46 
GeneralThis is very helpful. PinmemberAshaman7-Jun-05 1:29 
GeneralRe: This is very helpful. Pinmemberkubben7-Jun-05 2:16 
GeneralRe: This is very helpful. PinmemberAshaman7-Jun-05 2:18 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140916.1 | Last Updated 31 May 2005
Article Copyright 2005 by kubben
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid