Long Road

I began writing my final report this week. It sums up my learning throughout the course and the development of my project. After working on it for several hours I realize how much I've developed this semester. At the beginning of this project I had no idea how
I was going to make this work. I now have a good understanding of several technologies including .msi's, Wix and Xml.

When I started this project I had no idea what I was doing or how I was going to create .msi files. Soon after figuring out Wix I was able to create a Wix file that packages up Firefox. Then I was able to adapt that script to the newest vesion of Firefox. From there I was able to create C# code that actually creates a Wix script based on a Firefox installation. I never expected to get as far as I have with this project.

My learning throughout this course has not only helped me better understand Wix but it has actually helped me out in real life. I recently obtained a position with a company working closely with XML files. All in all I'm glad that I took this course and I hope to continue to work on my project in the future.

The Final Build

With my 0.9 build working properly (minus some small bugs) I am on my way to completing my final build. My .9 build had some very concerning bugs in it that I must fix for my 1.0 build. One of these bugs has to do with Wix and the way that Wix build scripts. To properly follow Wix formatting, Directory and Component identifications must be unique. Their id's should also reflect their name and this can be hard sometimes. In several area's of the Firefox folder there are folders called chrome or default. The way I've written my program is to take a random letter and attach it to the end of these folders . The problem with this is that if that 'random' letter happens to match anther 'random' letter then the program will not compile and a .msi will not be created. To get around this I have to figure out a smarter way of naming my folders but since they can sometimes be no longer than 6 characters, this could be hard.

The other bug that I have noticed in my program is if the user adds a '\' at the end of the directory field. This one is simple and should be easily fixed for my 1.0 build.

Lastly I'm planning on creating some error reporting so that if/when things do go wrong there will be some feedback for the user.

More soon,

Scratch that

Well totally ignore my last blog post. Most of it was psuedo code/theory and when it came to coding it just didn't work. Here is the problem, my first goal was integrate Mkaply's CCK extension into my program. Since CCK outputs an .xpi I figured I could write a static Wix script that would simply copy those files over and I'd be done. Problem is, like most extensions, CCK is dynamic which means that files change based on the installation. Sometimes a file will be there and sometimes it won't, for me to write a static script on this is impossible.

I've taken the same idea from my last post and changed it a bit. After several hours of work on a function I think I'm close to my goal. I've created a function in my program that recursively iterates through a folder and builds a Wix script dynamically. While I have the program creating the script properly, I have yet to test this. However if this does work it means that I can point this function at a directory and it will create a piece of Wix script for me dynamically based on that folder's content.

So far the code seems to work, I'll be testing more today.

Extensions?

After finishing my last build I was confident that I would be able to add in extensions with little to no problems. Once again, I was wrong. Extensions are stored in the extensions folder of the Firefox directory. Since Wix isn't dynamic and can't simply grab folders and package them, I have to figure out a different way of doing this.

Any way I do this is going to be problematic. I have to decide which extensions my packager will support and then build that support in. I am going to start with Mkaply's CCK extension. In theory this is how I envision the packager to handle extensions.

When a user selects an extension the packager program will actually open up the Wix script and write the code in to the script to copy an extension into the .msi file. It will copy the extension right from the packager install directory and not the Firefox install directory. This is to avoid bugs or problems that might occur if a user hasn't installed the extension properly.

If this doesn't make sense, I have created a diagram to illustrate the process. This week I aim to have my packager be able to package up CCK and create some error reporting. Providing all goes well for build .9 I should be able to add more extensions in for my 1.0 build.

Getting somewhere

Turns out my professor and I have had different ideas of where my project was going, I hope this road ends with some success. After much work over the last few days I finally have something to show for it. I've built a Wix script that works on the latest build of Firefox. This task wasn't too difficult but it was very time consuming. The debugging of my script took a long time as I was forgetting to copy airbag to the extensions folder. Once all that was done I was able to build my own .MSi from scratch.

There is TONS more work here such as integrating a license agreement etc, however I also need to get my packaging tool working. After brushing up my C# skills I created a tool that puts all this Wix stuff together with a nice GUI interface. Right now the script copies over the necessary files, creates some batch files and then compiles it all using the Wix toolset to create an .Msi.

Although I finally have a working product, there is still tons of work I have to do. Ideally I'd like to integrate Mkaply's CCK and other extensions so that network admins can create custom .msi's and push them over a network with extensions installed. I'd also like to do some more editing with the program so that it can copy over the necessary wix tools so that the end user doesn't need to have Wix installed to use my tool. All in all, I'm quite excited for this program and I think its going to be a success.

My build struggle

As of this week I have left my position with a company known as The Tech Zone in order to see this project through. It is in good timing that I find out my project needs to be 2.0 compatible.

Wix scripts are a basic XML files that tell the .msi where to put each and every file for the install. The XML file tells the installer where to put files including setup files, customized files and registry entrys. To bring my current 1.5.0.4 script up to 2.0 might take me days or weeks to do. I have to figure out where every single file that Firefox installs goes and map them in my Wix script.

At the same time I have created a program that automates the build process of Firefox, and can even install add-ons. Since I am working on this project full time I will continue to update my blog and the wiki continually and I am aiming to have something impressive for build 0.8

Wix or Custom App

I've decieded that instead of bringing my 1.5.0.4 msi build to Firefox 2.0 I will instead write some code that will allow an end user to customize the way that Firefox is installed. Though I eventually wish to bring my code up to date with the current vesion of Firefox, it will be very time consuming to do and I'd rather do something more intesting.

Having a brief understanding of Wix I figured I could use the tool to customize the .msi install of Firefox; I was wrong. Though Wix offers the user tools such as install directory, license agreements and installation types, it really doesn't give me the power I am looking for. Ideally I'd like to give the user the power to change the home page and other features inside Firefox. To do that, I'm going to need to write a tool that can change those features then call Wix functions to build the .msi.

This is the direction I am planning on going, where I start and if I can finish are two questions I can't answer.

Dave

First Wix Build

Today I finally completed my first Wix build, and it really wasn't too hard. I searched the net for some wix Firefox scripts and found one for Firefox 1.5.0.4. I downloaded it, and ran it. The script, if placed in the proper directory will create a .msi file that should install Firefox. After trying the .msi file and waiting for a couple of minutes it crashed. I realized there were some build errors so I went back to take a look at them.

Whether the script has some bugs, or I had a bad version of Firefox 1.5.0.4, I'm not sure. There were some file discrepencies and after fixing those the new .msi file was built. This time the script worked and I was able to make a successful firefox install.

This is great news for me. I didn't expect to be able to get it to build at all. Now I have to figure out which direction I'd like to go. Either work on the script so it works with Firefox 2.0 or start writing a program to edit the script.

More soon!

Dave

Actually Using Wix

My last posts have discussed the many issues that I've had with installing the Wix toolset. This post will instead discuss the power and flexability that the toolset has to offer. Not only was I quickly able to create a .msi file using a small script but I actually understood a lot of what was going on.

The Wix toolset uses xml to bundle files, shortcuts, and registry entrys into a .msi file. The thing that really seemed powerful to me is the fact that you can quite simply just add lines to your script that instruct the script to include more files. Its actually quite basic, and that really is important to entry-level developers such as myself.

There are however some problems with this setup. By adding a line or two you can include a file into your .msi but what if your .msi consists of thousands of files? It would take an extensive amount of time to build a .msi line by line for a massive .msi file.

All things considered, I'm very impressed with the Wix toolset. Its easy to use and its very powerful. To read more check out my posts on the DPS911 wiki:

http://zenit.senecac.on.ca/wiki/index.php/Firefox_Deployment_Kit#Builds

Under my build 0.3 section there is a link to my Wix script and the .msi that resulted from it.

The Wix Toolset (part Deux)

I don't know what's more frustrating, wasting time trying to install programs and get the Wix Toolset to work, or figuring out that you wasted all that time for nothing.

Turns out the Wix Toolset has binaries and didn't see them. Shortly after getting the source files to work I found the binaries for the Wix Toolset.

Well atleast I have a working tool now. More later...

The Wix Toolset

Just as I was starting to run out of steam someone *cough* Dave *cough* showed me an OS tool known as the Wix Toolset. The Wix toolset is a set of tools that help a developer write .msi's using xml files. As of today, I havn't got very far with it because of a several things. Firstly I found out the hard way that the Wix toolset isn't compatible with Vista. This isn't a 1/2 hour mistake, this took me about 2-3 hours to discover just because of the 1/2 dozen packages you need to install just to use the toolset.

Once I made that discovery it was on to the next. I have an old XP laptop at my house and decided I could use it. After once again installing the couple hours of programs I was onto anther problem Turns out the Wix toolset doesn't give you very good steps to building it. I was stuck on a screen that read "Please set WIX env var". Perhaps I overlooked it but nowhere on the Wix page did it say I had to set any environment variables. So I set an environment variable to the Wix directory and it began to work (somewhat).

As if right now I'm struggling with an error message that seems to be telling me I need anther SDK. I've installed everything that the Wix build page has asked for but somehow I'm still requiring anther SDK. I've put up a screenshot of my error message in hopes that someone might be able to help me out with this.

MSI's

Understanding that my work this semester has only been a compilation of documentation, I sat down this week trying to produce some tangible build. Here are some of the problems I'm facing as of right now. I've completed my research, I know how to push a build of Firefox over a network using a .msi file. As of recently I was able to use a .adm file to customize *some* features of the .msi install as well.

The only next thing to do is to create a tool that automates the whole process. A tool like Microsoft's IEAK that allows server admins to create a .MSI file based on fields they enter.

Thinking this was an easy task I began to install Microsoft's SDK kit for installers. Inside there is a tool called Orca. Orca is used to dissect and display the tables inside a .msi file. I decided that I would use Orca to take a peak inside the .msi file from FrontMotion. Inside I found a crazy mess of tables, some registry keys, some directory pointers and some I had no idea about. That is when I realized the true complexity of .msi files. They don't simply execute commands like a .exe, they have tables that indicate registry entries and pointers to directories to install files.

I've spend over eight hours this week trying to figure out this mess and still have very little to show for it. I was able to edit some fields in Frontmotion's .msi and I will be posting it on the wiki. I am hoping that my work will not be wasted and that by documenting this process I might be able to help someone else out that wants to attempt this task.

Pictures posted. 1) My simulated server environment



2) A screenshot of my work with Orca

New Direction

So I've find out some new things since my last post. Turns out that I lied somewhat in my last post, I said that I figured out to install Firefox remotely without any prompts. Well turns out that is only partially true. When the user tries to use the installed edition of Firefox it then walks him/her through the installer.

I decided to go back to my mock enterprise setup and try some other things with Server 2003 and Firefox. My thoughts in my last post were to somehow combine the efforts of MKaply's CCK and Active Directory to push a customized version of firefox. There are however a couple problems with this thought. Firstly, CCK creates an .xpi file that Firefox uses to customize it's features. Until I figure out how to bundle this .xpi file with the .msi file I have then this route is a dead end.

That being said, my next task is to look into FrontMotion's .Msi file and see if I can dissect it.

Next Step

Seeing as my first experiment went well, I plan on building on it. My next step (which I plan to post this Thursday or Friday) will include directions on customizing an install of a remote install of Firefox. This process is going to be new to me but with some help from fellow students and a little documentation, I think it should be easy.

What I have to investigate is MKaply's CCK add-on for Firefox. I havn't been able to play with it as of yet because my computer at home is Vista and the extension isn't really Vista tested. I am planning on using both CCK and Server 03 with AD to push a customized install of Firefox over a network.

Stay tuned for details.

Dave

Active Directory & Group Policies

After all my experience working in a corporate environment and working with software, I have never really had a chance to sit down and play with Active Directory. After about 30 minutes I already had a grasp on its concepts and uses. It, after all, is a pretty intuitive piece of software.

With a little bit of time I found a Microsoft document on pushing an install through Server 2003. Believe it or not, its actually pretty easy to do. I created a unique user group, a test user in that group and a group policy that pertains to that group. After a couple of hours of reading a playing around I was successful in pushing a Firefox install through Server 2003 to my user. It installed with almost no visible sign of the installation. I logged in as my test user and it was there, seamless and painless, Firefox was installed.

For more information on the process, read my Jan 25th build post.

An Introduction, again

After setting myself up on IRC and updating my Seneca wiki profile, I realize I have stepped back into the world of OS software development. Interestingly enough, I have been through most of this before but one important factor has changed since I took the prerequisite to this course, my physical presence. Working away from school has already added an interesting and unexpected twist on my motivation. I find that I am actually getting a very realistic insight into what many developers experience. I can't rely on others to do my work, but rather constantly work with others to accomplish my goals and help them accomplish theirs. It will be a good experience for me regardless of my accomplishments, as a I will have to exercise the communication tools such as IRC, blogs and email while working on something new and exciting.

Should be interesting.