Introduction
This is the part 3 of a series. There is a problem with storing .NET applications on a network share. When you want to release a new version you need to make sure everyone is out of the application. This article presents a solution I came up with, to solve figuring out who is in the application so you can ask them to get out. You may want to read the first two articles:
Background
Even though a .NET app is run locally on the user's PC, a .net app on the network share has an open file lock on it. So you really have two options to discover who has the application open. The first is you need to be a network administrator and have rights on the network server that the share folder resides on. If you meet these requirements, then you can just open the computer management (right click on My Computer then Manage). Then click on Shared folders. Finally Open files. If you are an administrator on your own PC you can try this out just to see what I am talking about. It is important to note here that I do not have administrator rights, which is why I came up with this solution. The second option is to use the programs I wrote so that help desk or release coordinators or whoever can see who has what app/file open.
Overview of the Solution
First, you need to know that there isn't some magic solution. There is setup to get this solution to work. Here is the layout of the solution. You have a Windows service that calls an existing program called openfiles.exe. The openfiles.exe can be found at c:\windows\system32\openfiles.exe. If you can not find this program then you are out of luck. The Windows service is logged in as a domain user that has been added to the Power Users group of the network server you want to see the open files on. The Windows service writes out the list of open files to an XML file on a network share. Then there is a Windows client that reads the XML file and displays the servers and open files. Note the Windows service can run on any network server that has the openfiles.exe. The Windows service uses an XML INI file to know which network servers it should be querying. This XML INI file defaults to c:\. The network share that the XML files get written to can also be anywhere as long as both the Windows service and the Windows client both point to the same place. Note the openfiles.exe is something that is provided by Microsoft. It allows you to query the open files on a network server assuming you have the correct rights on the server. The Windows service will write out one file per server per minute. The Windows client will always try to read the XML file from the previous minute. So yes, this means you will have 60 files per server. If you have a lot of open files, the XML files can get big. Note the source is provided, you are welcome to do better than this.
The Solution
First you need a domain user that is a member of the Power Users group on whatever network server you are interested in. This domain user is used for the login for the Windows service. Next you need to install the Windows service. You need to use the installutil program that comes with the .NET framework. It can usually be found in c:\windows\microsoft.net\framework\v1.1.4322\installutil.exe (Note v1.1.4322 should be replaced with whatever version of the .NET framework you are running). So copy the Windows service to a local drive on a network server. It is usually a good idea to create a services directory. Open a command prompt. Change directories to get to where you saved the Windows service. Run installUtil (c:\windows...\installutil openfilesServer.exe). You will be prompted to enter the domain user and password. Next go into Computer Management. Then Services and Applications, then Services. You should see OpenfilesServer. Start the service. A OpenFilesini.xml file will be created. Stop the service. Locate the Openfilesini.xml file and edit it so that the output directory and the network server(s) you want is/are correct. Don't forget to add the domain user to the Power users group of the network server you want to see the open files on. Once the OpenFilesini.xml file is setup properly, start the Windows service. Note, the default place for the service to load the INI XML file is c:\. You should start the service to see the XML files getting created. Now we are ready to use the client. The first time you run the client Windows app, you guessed it, Openfilesini.xml file will be created. Close the app and edit the Openfilesini.xml file to point to the correct output directory that the Windows service is writing to. It should be a network share some where. Start the Windows client and you should see your listing of network servers. Once you select one, you will see the list view of all the open files. Note, the client does checking to make sure the files are current and are not from yesterday.
Some Code
Here is some code of the call to the openfiles.exe:
Dim myprocess As New Process
myprocess.StartInfo.FileName = "c:\windows\system32\openfiles.exe"
myprocess.StartInfo.Arguments = "/query /s " + infileserver + " /v"
myprocess.StartInfo.UseShellExecute = False
myprocess.StartInfo.CreateNoWindow = True
myprocess.StartInfo.RedirectStandardOutput = True
Try
myprocess.Start()
If Not (myprocess.StandardOutput Is Nothing) Then
Dim tmpstr2 As String = String.Empty
DSFileData.Tables(0).Clear()
DSFileData.Tables(1).Clear()
Dim values(6) As Object
Dim values2(0) As Object
values2(0) = DateTime.Now
Dim cnt As Integer = 0
Do
tmpstr2 = myprocess.StandardOutput.ReadLine
If Not (tmpstr2 Is Nothing) Then
cnt += 1
If cnt > 5 Then
values(0) = tmpstr2.Substring(0, 15).Trim
values(1) = tmpstr2.Substring(16, 8).Trim
values(2) = tmpstr2.Substring(25, 20).Trim
values(3) = tmpstr2.Substring(46, 10).Trim
values(4) = tmpstr2.Substring(57, 10).Trim
values(5) = tmpstr2.Substring(68, 15).Trim
values(6) = tmpstr2.Substring(84)
DSFileData.Tables(0).LoadDataRow(values, True)
End If
End If
Loop Until tmpstr2 Is Nothing
...
Process myprocess = new Process();
myprocess.StartInfo.FileName = "c:\\windows\\system32\\openfiles.exe";
myprocess.StartInfo.Arguments = "/query /s " + infileserver + " /v";
myprocess.StartInfo.UseShellExecute = false;
myprocess.StartInfo.CreateNoWindow = true;
myprocess.StartInfo.RedirectStandardOutput = true;
try
{
myprocess.Start();
if ((myprocess.StandardOutput != null))
{
string tmpstr2 = String.Empty;
DSFileData.Tables[0].Clear();
DSFileData.Tables[1].Clear();
object[] values = new object[6];
object[] values2 = new object[1] {DateTime.Now};
int cnt = 0;
while (myprocess.StandardOutput.Peek() >= 0)
{
tmpstr2 = myprocess.StandardOutput.ReadLine();
cnt += 1;
if (cnt > 5)
{
values[0] = tmpstr2.Substring(0, 15).Trim();
values[1] = tmpstr2.Substring(16, 8).Trim() ;
values[2] = tmpstr2.Substring(25, 20).Trim();
values[3] = tmpstr2.Substring(46, 10).Trim ();
values[4] = tmpstr2.Substring(57, 10).Trim();
values[5] = tmpstr2.Substring(68, 15).Trim();
values[6] = tmpstr2.Substring(84);
DSFileData.Tables[0].LoadDataRow(values, true);
}
}
...
Conclusion
So this was just a programmer's fix to get around my lack of rights. Using the Openfiles.exe is a powerful tool to see who is in a file. Beware, the openfiles.exe also allows you to break open file connections. I did not include the functionality into this app, but it could be done. So I hope you have fun with this if your network admin will allow it.