Business Systems Analyst - Clearing - SQL Server - ASP - VB (IL) Next Step Systems US-IL-Chicago Post A Job | Post A Resume

Executing applications on a computer from a remote location is something that many developers wish they had the ability to do. Well, here is a solution! You could write an ASP page so that you can go anywhere in the world, go to your server and execute a program that resides on your server - the possibilities are virtually limitless (you'll encounter a limitation in this article) to what you can use this for. On an intranet, this becomes particularly useful because there are many different uses for this application and you don't have to worry about security as much. For this article (my first) I am going to explain how to do this through a detailed example. Here is the scenario:

Say you have a computer that is responsible for building the latest setup program for your internal tool. The process for building the build is simple: get the latest versions of the files from your source code management tool, compress certain files, and build the setup. In this case, we are using Microsoft Visual Source Safe 6 (VSS) as our source manager. So you want to create an ASP page where anybody on the intranet can visit, build the setup, and download it so they know they are getting the latest possible version. For this article, I will show you just the first step (getting the latest versions) - the rest of the process you can figure out and it will be different for every case.

This is where Genusa comes to the rescue (yet again). There is a free component provided by Genusa at http://www.serverobjects.com/products.htm#Aspexec called ASPExec which lets you execute command applications through an ASP page. The idea here is to execute a DOS batch file (eek!) that will do everything you want it to do. Lucky for us, VSS has a great command-line interface that will let us do just about anything we want with it. For more information about that, see the VSS Help File, it has all the switches, flags, and do-hickeys. But all we want to do is get the latest versions of the files in a certain project. It is important to note that the VSS server is located on the same computer at the web server. Why, do you ask?

Note: This explanation is somewhat technical. I have looked into this issue for weeks and tried workarounds but in the end, nothing worked. Basically, here is the story: in our batch file, you can see that we set the "ssDir" directory to a directory on our computer, so ss.exe has only to go to another directory on the drive to retrieve the information about the VSS project. But, when trying to enter something like "\\buddy\vss\" as your "ssDir" variable, you will notice that VSS won't be able to go across the network to get the information about the VSS server. This is because the IUSR_COMPNAME username on the NT machine does not have access to use the network resources on the server. I have tried giving IUSR_COMPNAME certain access and all types of things but nothing seems to work. People across the network can check in files to your VSS server freely, don't worry. Please note that your batch file will work with a VSS server across the network as long as you are executing it from the desktop and not through IIS. This is because YOU have access to go across the network, but not the IUSR_COMPNAME user that goes through IIS.

So, what we'll do is go ahead and create the batch file that will get the latest versions of the files:

That's it! Now go ahead and test the batch file by running it on your machine. If it gets the latest versions of the files, then all you need to do is make your ASP page execute the batch file through the page and you're in business. The steps to create your ASP page are as follows:

1. Install the ASPExec component (register the component ASPExec.dll).
2. Create the ASP page (let's say build.asp) and make sure the user will have execute access on that file/directory.
3. Create the object on the page using CreateObject()
4. Set your parameters for the object
5. Call the Execute method
6. (Optional) Make sure it worked by checking a timestamp of a file.
7. If you are lazy enough, you can do the timestamp check using Genusa's free "LastMod" component.

<%@ Language = VBScript %> <% Option Explicit %> <html> <head> <title>Get Latest Versions</title> </head> <body> Getting latest versions...<p> <% Dim objExecutor Dim sResult 'Create the server-side object Set objExecutor = Server.CreateObject("ASPExec.Execute") 'Set the application name 'For NT systems, it's "cmd.exe" 'If you're running something else then I think you know 'what it is :) objExecutor.Application = "cmd.exe" 'Now set the parameters, very important! 'You want your DOS prompt to call your batch file 'For NT - it's "/c filename.exe" objExecutor.Parameters = "/c c:\latest.bat" objExecutor.ShowWindow = False 'Here we execute the app and get the output to this string sResult = objExecutor.ExecuteWinApp Response.Write "Result: " & sResult & "<p>" %>

Done getting latest version.

Latest version of setup.ini file is

<% Dim objFSO Dim fFile Set objFSO = CreateObject("Scripting.FileSystemObject") Set fFile = objFSO.GetFile("C:\Program Files\Microsoft Visual Studio\Installer\setup.ini") Response.Write FormatDateTime(fFile.DateLastModified & ".",vbLongDate) %> </body> </html>

That's it - now test, test, test! It "should" work alright and you can experiment with doing very interesting things.

Attachments: