Wise Package Studio, Part 5: Package Dot NET Framework 2.0
In the previous articles I showed you how to install and configure Wise Package Studio 7, and I helped you build your first package. Also I showed you how to use the Virtual Package Editor and how to use Wise Script. Now it is time to do some hard stuff.
In this fifth article of Wise Package Studio 7, I'm going to guide you through a two-step process.
First I'll guide you through the repackaging of Dot NET Framework 2.0, and then we are going to build a VSA of Dot NET Framework 2.0.
First we are going to create a new project named Dot NET Framework 2.0
As you see I named the project Dot NET Framework 2.0. The status is left open.
The Application name and the package name is Dot NET Framework 2.0. I downloaded the Dot NET Framework and I saved it into my software repository. For process I select Repackage for Windows Installer.
If you do not have the Dot NET Framework on your computer, you can download it from: http://www.microsoft.com/downloads/details.aspx?Fa...
Click Close to save the project.
Click Create the package. Now we see the first screen in our process.
Click Next to continue.
In this case I select Snapshot. This will create the package on my computer. If you already have installed Dot NET Framework 2.0 on the computer, then it is better to use the Virtual Capture to get it captured in the Virtual OS.
Click Next to continue.
Select Rerun the initial scan. I have updated my server with the latest patches, and this will ensure that there is no information in the package that does not belong to Dot NET Framework, but to the patches. Click Next to scan the computer.
Now you see a screen where you have to select next to continue. This screen is built in as a reminder to close all applications that are open at the moment. During your capturing process it is not wise to have the Internet Explorer or other applications open. Every application that is running is leaving traces that will prevent the process from capturing them correctly or that are captured and then they end up in your newly created package.
Now we can capture the application. You have two options. The first one is click on the button execute. This will help you when you need to capture more applications. If you only have to install one package, then you can click Next on the bottom.
Click Next to start the installation.
Now the installation will pre-configure your computer, extract the executable and prepare everything for the installation.
When the computer is ready and the executable is extracted you see the Dot NET Framework welcome wizard. Click Next to continue.
Select the button to acknowledge the license agreement. Then click Install to start the installation.
Now we have our package built. The next step in the process is to edit, test and deploy the package.
Click Finish to close the screen that tells us that the software is installed correctly.
Now before we run the initial scan we have to reboot the computer to make sure all processes are finished and nothing is forgotten. Just leave Wise Package Studio open. It will automatically start and then you can run your initial scan.
Click Next to perform the final scans. During this step Wise Package Studio creates a new snapshot.
Then the initial snapshot and the final snapshot are compared together. All the differences will be our package. This process takes up to 5 minutes. So let's grab a cup of coffee to survive the next stage in building a perfect package.
As you see I have some residue between the scans that definitly do not belong to the package. Above you see them highlighted in blue. I mark them, and then exclude them from the package. This process is not only for the files and folders, but also for the registry.
Click Next to see all the exclusions.
Now we see all the exclusions. Some of them are excluded because I selected them in the previous screen, others are excluded because these are already selected while I built my Workbench project.
Again we see the files and folders here where we also have to check the registry.
Click on the exclusion type to change to the registry exclusions.
When you have checked everything click Next to continue.
Check the name and the version number if you feel it is incorrect. The manufacturer is Microsoft. The default Directory for the Dot NET Framework is c:\Program Files.
Our destination Feature is completed.
Click Finish. Now our Package Capturing Reports are generated and the file dependencies are checked. Do not click Finish until you are absolutely sure the process is finished. Clicking Finish too soon will prevent the process from finishing completely and the package will not be ready to go in a roll out.
You can now edit the package if you like. Because of the great variety of settings it will not be really helpful to do it in this article. To learn this you actually have to do it. And every time you do you learn new things.
Our next step is to import the new package into the Software management database.
Click Run to start the process.
Now we can start the conflict manager.
Select the packages and see if they have conflicts.
When you have checked for conflicts and resolved them if necessary, you can go to the final step in our process.
Distribute your package.
Now we have built a new package that is tested for conflicts with our existing packages. The package can now be safely deployed to all our clients.
In the second step of this article I'm going to show you how you can build a VSA of Dot NET Framework.
First of all we have to uninstall it from our packaging machine, or else the software will detect that it is already installed, and building the VSA will not succeed.
You may uninstall the software by typing appwiz.cpl in the Start Run, and then select Microsoft Dot NET Framework 2.0. Click on it and un-install it completely. You can ignore the warning that other applications will not work when Microsoft .Net is not installed.
Now start Wise Package Studio again.
Start the Virtual Package Editor.
Select Set-up Capture and click OK to start creating the virtual package file.
Microsoft Dot NET Framework can be captured in a single program capture. Select it and click Next.
Now we have to select the executable.
Instead of selecting the original one we take the repackaged one that we have compiled.
Click Next to continue.
Click Next to confirm the welcome screen of our newly created package.
Then we have to select the default install path.
Click Next and again Next.
The installation will now start and the process file will be created.
Again we are able to exclude files or folders. It is not necessary because we used our own created Repackaged Dot Net. Just click Next to continue. And again Next.
Fill in the screens, and select the source location where you would like the files to stay.
Click Finish to build the file.
Final step is to compile the WVP.
Click on Compile in the right.
Give the WVP file a name and save it in your SVS directory.
After the process is finished you have a WVP file and a VSA.
You now have successfully packaged Dot NET Framework 2.0.
Now I hear you all thinking? Why not do it with SVS and take this long road?
Well, the answer is very simple. With the normal SVS admin it is almost impossible to capture the service that this software is installing on your machine. The reason is that the service is installed and started with a non-standard routine. During the process in building our own repackaged Windows Installer file we captured the service and now we are registering it with the normal routine. That routine can be captured.
After the package is completely compiled you have two packages. The first one we created is the MSI that can be locally installed.
The second one is the VSA that can be enabled and disabled with a simple push on the button.
The virtualized one will make it easier for us when you have an application that needs the 1.1 version.
Various applications are still programmed to check for version 1.1. If this is hard coded into the installer there is no way to get the software installed. When you deactivate the 2.0 package the software will get installed. Version 2.0 is fully backwards compatible with the older version, so for the functionality of the older program it is not necessary to have the 2.0 versions de-activated. It is only necessary for several installations.
Wise Package Studio, Part 4: Start Guide for the Virtual Package Editor
Wise Package Studio, Part 6: Building an XP Client Packaging Machine