NET project and name it Program. Add the following placeholder code to the class:. Open the properties dialog of the main VB. NET project and perform the following changes in the Application tab:. Note that if your main application project is a C project, the Program class with the placeholder Main method is created automatically.
You still need to change the root namespace anyway. You may ask, "Why do we bother with a Main method instead of placing the startup code in the main form load event? So, we need to be able to execute code before any form is created. Now we'll fill in some information about the application in the AssemblyInfo files of each project. In C projects, it is in the Properties folder. In the VB. NET project, it is in the My Project folder, but in this case you first need to activate the Show All Files icon in the solution explorer window.
For the main application assembly, that's the data we will set up:. Setting up metadata is not strictly necessary, but it is good practice. Killer Application uses this data in the about box. Test case 1 states that all application executable files must "contain an embedded manifest that define its execution level. Visual Studio makes this task easier, by the way, but we'll assume we all are poor Visual Studio users here.
Luckily, there is an indirect way to do this. In the application main assembly the VB. NET executable , add a new text file and name it Killer Application. The file name must be the same as the assembly name, plus. Ensure that in the properties page for the file, the Build Action is set to None. Then open the file and paste the following inside:. The contents of the manifest file is always the same; only the file name itself changes.
This manifest file will be processed by the project post-build events, as we'll see right now. Remember the vistatools directory we created once upon a time? Well, it's now time to use it. We will set the post-build events of the projects so that some nice things are done with the generated assemblies. In the properties window of the VB. NET executable project, select the Compile tab, click the Build events button, and in the Post-build event command line box paste the following:.
Note: actually, there are only two commands to execute. I have divided them in separate lines each to improve readability. In the post-build event window of Visual Studio, the commands must be in one single line each. In the first command, we use the manifest tool to embed the manifest file in the resulting assembly.
The second command will sign the assembly, thus fulfilling test case 5 "verify application installed executables and files are signed". Note that you will have to change the capsulekey. If you don't have an organizational certificate yet, but still want to compile the application, just remove this line or, better, disable it by prepending a rem command to it. That's because, when generating the installer, the executable file to be packed will actually be taken from the obj directory.
That's the file we want to be "manifested" and signed, rather than the one used for debugging and testing in the development machine. Now let's go with the support assemblies. For both KillerApplication. Support and KillerApplication. Install , open the properties window, select the Build Events tab and, in the Post-build event command line box, paste the following note again that it is a single command divided into four lines :. Yes, it is exactly the same as in the case of the executable file, but without the manifest stuff.
Again, if you don't have an organizational certificate yet, remove or comment the command temporarily. The first version of post-build events two commands must be set on all projects that generate an EXE file. The second version one command must be set on all projects that generate a DLL file. That's all you need regarding project setup except for the installer project, which we will dissect later. Now you need to add the application code and the auxiliary data images, texts, datasets, whatever to the projects.
You can use whatever code and data you need Before we plunge into the intricacies of the source code, we'll take a look to another subject that also needs attention: the application data. That is, all application files that are part of the project but are not code. Visual Studio lets you to add these kinds of files to your projects. Just right-click on the project and select either Add new item or Add existing item. Then in the properties page for the item, make sure that Build Action is set to Content.
Killer Application has three files of this kind inside the data folder of the main project: one photography, one text file and one database file, as shown in the following image:. The question is: where do these files go when the application is generated? The answer is that it depends on how you generate the application:. In both cases, the original directory structure is preserved. It is now the moment to take a look at test case "verify application installs to the correct folders by default.
If you cheat a little and scroll down or better, look into the Killer Application solution , you will see that the Killer Application installer creates a directory named, of course, Killer Application , and puts all the project content files here:. So with all of this in mind, you probably think that it would be nice to use a single code base to access the application data on all cases, wherever the data is placed.
And you are right. Here is how I have achieved it in Killer Application:. We are now really ready to look at the source code of Killer Application.
We'll look at the boot sequence, then we'll see what the menu entries on the Killer Application main window do, and finally we'll examine the custom actions contained in the installer support project. We'll start the source code dissection at the boot sequence, that is, the code that Killer Application executes at startup.
Open the Program. Test case 32 says: "verify that the application only handles exceptions that are known and expected. Shouldn't we just let alone unexpected exceptions here?
The problem is what you can read in the "verification" part of the test case: "There must be both an Error message with 'Source' listed as Application Error and an Information message with 'Source' listed as Windows Error Reporting for each executable above in order to pass this test case.
Hence, we must generate it by hand, and that's exactly what this weird piece of code does. After the logging is done, the Throw statement rethrows the exception unmodified, so everything is OK and we pass the test case.
Note that at the end of the catch block, we must use Throw and not Throw ex. The former will rethrow the original exception with the original call stack preserved, while the later will generate a new exception that will cause the call stack to be lost and will also cause test case 32 to fail, I admit I have no idea why.
Without this, you will receive this ugly error window instead of the fancy WER window in case of unhandled exception:. Test case 9 says: "verify application launches and executes properly using Remote Desktop. How can the test case pass then? The answer is in the small print. There is a note in the test case description that says: "if application does not support Remote Desktop, it must pop-up a message indicating this to the User and write a message to the Windows NT Event Log in order to pass this test case.
The failremote command line switch is a trick I use to exercise this functionality without actually having to set up a Terminal Server connection. It can be removed in real applications.
By the way, credit for this piece of code goes to mister Amitava. Test case 8 says: "verify application launches and executes properly using Fast User Switching. And again, the small print saves us: "if application does not support concurrent user sessions, it must pop-up a message indicating this to the User and write a message to the Windows NT Event Log in order to pass this test case. So we'll do something similar to the case of the remote desktop execution, but a little more complex.
We will first check if Killer Application is already being run by another user ; if so, we show an error message, we create the appropriate event log, and we terminate. If not, we check if Killer Application is already being run by ourselves ; if so, we activate the main window of the already running instance. We will need a little of "advanced" code to achieve this. In the support project you can find the AlreadyRunningChecker class it should be in the main project, but I had the code in C and I was too lazy to convert it to VB.
With the help of this class, we can properly check the presence of other application instances in the following way:. I got most of the code of the AlreadyRunningChecker class from somewhere on Internet but I can't remember where. We have spoken about this before: the application data files all application files that are not code are placed in different locations depending on whether the application is run from within Visual Studio or installed using the generated MSI file.
We will use the global variable Program. DataDirectory to store the actual path of the data files. The following code will set up the contents of this variable:. There is an extra thing to do after the DataDirectory field has been set.
One of the data files of Killer Application is a database file, accessed via a typed dataset. If you look at the settings file, you will see that the connection string used is as follows:. But look at the AttachDbFilename key: it points to the directory where application data files are placed. Can this value be changed? Yes, and that's what we do right now:.
By default, this setting is not set i. Since we can have the database file in a number of different places, we need to appropriately set this setting so that SQL Server can find the database file. Moreover, if you hate global variables, you could directly use this application domain setting instead of the Program. DataDirectory variable to obtain the data files path. Simply use this code to obtain its value: AppDomain. GetData "DataDirectory". There is however a problem with this approach.
With this connection string, whenever you try to edit a typed dataset to add a new TableAdapter, for example Visual Studio will complain that it can't find the database file. That's because Visual Studio always assumes the default value for the DataDirectory setting, therefore, while editing the dataset you need to do the following modification in the connection string:. This is actually not necessary but I do it as an example of modifying a file in the data directory which theoretically is an issue when uninstalling the application, we'll see later why and how it can be solved.
Simply, a line of text containing the current time and user name is appended to a file named log. Test case 2 says "verify Least-Privilege Users cannot modify other users documents or files" , and test case 3 says "verify Least-Privilege user is not able to save files to Windows System directory". The good news is that you don't need to do anything special to fulfill these test cases, as the operating system will grant or deny access to files and folders as appropriate.
You must simply be sure to properly control the exceptions that will be thrown when trying to read or write where you the user, actually are not authorized to. The File menu in Killer Application will help you with these test cases. It contains two entries, Open and Save , that allow to create and open a text file. Any generated exception will be caught and its associated information displayed. There is a text box where you must enter the path where a text file will be created.
Three buttons allow you to populate this text box with three "interesting" locations: the Windows system directory, and the home directories for the logouser1 and logouser2 users these users must be created for testing the application, as explained in the test cases specification document. You can also select any directory by using the directory tree that appears when clicking the " Tuesday, July 24, AM.
I did the following: Kicked off another code signing cert request from my client's CA server. Dumped these both into a directory and used pvkimprt. Friday, August 3, AM. I'm a novice to Code Signing. I have also recently bought a code signing certificate from a CA and am not able to see it using "Select from Store".
I would like step by step instructions on how to "Sign the ClickOnce Manifest" as well as additional steps to "Sign the assembly" Thank you,. Wednesday, July 25, PM. Thursday, August 2, PM. Otherwise, you can find compiled binaries directly from the OpenSSL website or consult your Operating System's package management feature. Extracting the private key. Download the PVK transform utility. To download pvkimprt. The pvkimprt. Make sure you install the file before running the pvkimprt command.
Importing the files.
0コメント