Like many developers, I tend to forget about the installation process. In the past, I have thrown the product over the wall and left the installation to process to someone else. I knew this practice was less than optimal, but it was what I had to work with. On my last project, I took ownership of the full process including installation. Given that I did not want to pay too much money for yet another copy of an installation-building product, I decided it was time to learn to use Wix. While I will not say that Wix is wonderful, the price is right and it is, in many ways, less frustrating than the commercial products.

Wix has the advantage that the installation builder is close to the Windows Installer database tables so the possibility of the tables not being built right is small. Wix’s advantage is also its disadvantage, in that the user must learn the Windows Installer before they can do much with Wix. I realized that the commercial GUI installation builders and the Visual Studio setup projects are masking a lot of information. I also discovered that many issues with past installations were due to a lack of knowledge about the Windows Installer because the GUI products made the whole process seem simple, which is as far from reality as can be.

On first look, starting a new installation project with Wix is an overwhelming task. As you begin to read the Wix documentation, you rapidly understand you will be creating many GUIDS and doing a lot of typing. I attempted to create an installation without reading the Windows Installer documentation. While it is possible to create a usable installation without aide of the installer documentation, having more than a glancing familiarity with the Windows Installer will certainly help you create better installations.

Wix has some tools that automate a lot of this process, but they should be avoided on the first attempt. I say avoid them, not because they are bad, but because they can easily put the user in the same place as the GUI installers; too much masking of what is really happening. Misusing the tools can cause many undesired side effects.

It took me two days to create a simple install that had sixty components, many of which were shared between the two installable features. That time included understanding how to create the Start Menu entries and populate all the fields in the Add/Remove/Programs table (keep in mind that Wix is the assembler level code of the installer and it does almost nothing for you automatically). After the two days, my install would correctly clean up upon “un-installation” so that there was no trace of the program left on the system (the complete cleanup is something that the installer documentation and the Wix developers stress). I have not yet attempted patches or upgrade installs and I suspect that I am violating installer rules such that these will not work; so more reading on major and minor upgrades.

I had to include the call of a managed code installer class (System.Configuration.Install.Installer). While this is a bit difficult, the hardest part was figuring out how to do it. The process is almost completely devoid of documentation. The first thing I had to get into my head was that calling the Installer class was really a managed custom action. As soon as you mention managed custom actions, many people form a defensive circle and tell you that you should not write one. Both the Wix developers and the Windows Installer team discourage their use, but they can be extremely useful and, when done correctly, do not violate any of the installer’s rules. We would all benefit from the Windows Installer team removing their heads from the sand and embracing managed custom actions or even better if they would create a standard action to call a managed Installer class, but I am not holding my breath. Anyway, a day later, I had the custom action working and correctly cleaning up upon product removal.

We have recently added two flash sites to our portfolio using the WIX platform and found it to be very easy to use as a WYSIWYG flash platform and is sufficient for most needs, especially if you are heavy on the media and galleries. And what really makes WIX great is that it is FREE! Although the stability of the platform is definitely something WIX should consider. Other than that, it is a great platform for small business owners wanting to get a FREE flash website. They even have a E-Commerce package where you just drag and drop a shopping cart which is great too but that is a commercial service and would require a monthly fee. You can visit them at http://www.wix.com or take a look at http://www.wix.com/ConsultingCents/Consulting-Cents and http://www.wix.com/ConsultingCents/Sophisticated to see what Consulting Cents could create using WIX. The images below showcase what it generally looks like.

I hope you will find this information useful (especially on the cost savings part) and please let us know your feedback on this WIX platform.

As I looked to get back into wedding photography I searched for a low cost (free) website provider and came across Wix.  The attraction was that it is flash based so you can create a super cool site that looks slick and professional.  Unfortunately I soon found that I really needed absolute page addresses and the ability to copy text from the pages for responding to emails, something that is not possible with a flash site.  I moved to another site host, but that will be for a future post.

Setting up a site at Wix was somewhat easy.  Once you have your account created you can choose from various templates and modify the look from there, or you can build your site up from a blank page.  The free site will have a tag line for the Wix service, but they offer a premium upgrade that will remove the tag and open additional features.  Overall I found the service to be very good and the end result was very professional and attractive.  If you are looking to build a flash site on the cheap and don’t care about having absolute web addressing then Wix could be for you.

Finalmente, después de haber investigado todas las páginas creemos que la más completa, fácil de utilizar y además con mayores posibilidades creativas es Wix. Esperamos vuestra opinión. Os dejo aquí la URL con lo que hemos hecho para probarla aunque también la hemos incorporado a la entrada anterior.

Ahora abría que trabajarlo más y ponerlo más atractivo porque lo que hemos hecho ha sido muy por encima simplemente para probar.

Por cierto, aprovecho para anunciaros que os he enviado un mail con la contraseña de wix por si hace falta.

Deployment of web sites is usually done by copying the compiled ASP.NET web site files into the target virtual directory by using Copy Web Site or Publish web site features in Visual Studio and by manually creating and configuring the Web Site in IIS.

Though this method is simple, it involves lot of manual effort in verifying the Pre Requisites, Creating/Modifying or Configuring the Web sites in IIS. We can automate this whole process by building a simple Windows Installer Package using WIX in the Visual Studio itself while working on the development of your site.

The installer using WIX can

· Check for all the Pre Requisites (OS Version, IIS version, and .NET Framework etc..) before applying any changes

· Create/Modify the web site, Application Pool and configures it in IIS

· Provide the features like Install, Un-Install, Repair and change to the site

· Remove everything that is created (Web Site, Physical Directories) on Un Install and leaves the target server in clean state with just few button clicks

· Rollback all the changes in case of failure

Create a Sample Web Site:

Let’s create a simple website and add a Web Deployment Project to the Web Site. We will build the installer package to deploy this web site on to the target server.

Fig 1: Sample web site and its Web Deployment project

Right click on Web Deployment project and open the Property pages to set up the output location for our compiled web site files. Leave the default value which is set to project output folder. This location we will be the source for our installer package to pick up the required files while building the installer package.

Fig 2: Web Deployment Project property pages

Fig 3: Files in Web Deployment project output folder

Authoring Installer for our Sample Web Site:

We need to install the WIX 3.0 version from http://sourceforge.net/projects/wix/files/ to add the WIX plug-in to the Visual Studio. (Please use WIX documentation for basic understanding on Directory, Component and Feature elements in WIX source files)

Now add the new WIX project to our solution. After you add it the solution looks like this

Fig 4: The web site and the set up project together in one solution

The Product.wxs is the WIX Source File which we will modify shortly to define our package components. Before that we need to add reference to WixIISExtension.dll and WixUtilExtension.dll to our WIX Project. Now open the Product.wxs and add the following xml namespaces to get the intelliscenece for WIX IIS and other elements.

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension"
     xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

The default directory structure defined in WIX source file maps to “C:\Program Files\ApplicationName\” which specifies the target install location for our package i.e. the location on target server which will have all the output files from our MyWebSite_deploy project (See Fig 3).

Now add the following under the INSTALLLOCATION directory to define our first component

<!-- root level files –>

<Component Id="MySite_root_Files" Guid="E06FD7E9-8360-4e78-B10F-3F53E88FE1FB">
 <File Id="MySite_Default_aspx" Source="$(var.SolutionDir)\MyWebSite_deploy\$(var.Configuration)

                                        \Default.aspx"/>
 <File Id="MySite_Web_Config" Source="$(var.SolutionDir)\MyWebSite_deploy\$(var.Configuration)\Web.Config"/>
</Component>

The component MySite_root_Files defines all the files that are directly needs to be copied under the INSTALLLOCATION. The <File/> element specifies the actual file that needs to be copied and the source attribute specifies the complete source path of the file.

Source="$(var.SolutionDir)\MyWebSite_deploy\$(var.Configuration)\Default.aspx"

$(var.SolutionDir) is a WIX pre-processor which gives the Solution folder path to the WIX compiler

$(var.Configuration) is another pre-processor which specifies the Active Configuration of the solution (i.e. Debug | Release)

Along with the files Default.aspx and Web.Config we also have bin folder in project output directory which needs to be created under the install location. So create the folder mapping \INSTALLLOCATION\bin by adding the directory element like below under the INSTALLLOCATION directory. And define the component and file or Directory element for each of the files and directories under the bin folder as we have done for INSTALLLOCATION directory.

<!-- bin directory –>

 <Directory Id="MySite_bin_Directory" Name="bin">
   <Component Id="MySite_bin_Files" Guid="2ECC2543-856E-4ca7-8DB3-D1657245A41E">
     <File Id="MYSite_MySite_deploy_dll" Source="$(var.SolutionDir)\MyWebSite_deploy\$(var.Configuration)

             \bin\MyWebSite_deploy.dll">
      </File>
    </Component>
  </Directory>

The same way we can add any number of directories and files mapping from source to the target location.

Setting up IIS web site:

So far we have seen how to move files from source to the target location by using the Directory, File and Component elements. But how can we configure IIS?

WIX has an API or an Extension (WIXIISExtension.dll) to interact with IIS. Remember that we have already added reference to this to our WIX Project. Add another component under the INSTALLLOCATION directory to define the configuration to create a web site in IIS.

<Component Id="MyWebSite_IISConfigure" Guid="5146762F-0E78-47d2-A105-6E18E2993619" KeyPath="yes">
  <util:User Id="MyWebSite_AppPoolUser" Name="domain\username" Password="pwd"/>

  <!-- define application pool -->
  <iis:WebAppPool Id="MyWebSite_AppPool" Name="MyWebSiteApplication"
                  Identity="other" User="MyWebSite_AppPoolUser"
                  RecycleMinutes="120" />

  <!-- define web site -->
  <iis:WebSite Id="MyWebSite_Website" Description="MyWebSite"
               AutoStart="yes" StartOnInstall="yes" ConfigureIfExists="yes"
               Directory="INSTALLLOCATION" ConnectionTimeout="360" >

       <iis:WebAddress Id="MYSite_Bindings" IP="xx.xx.x.xxx" Port="80" Header="MyWebSite" />
       <iis:WebApplication Id="MY_WebApp" Name="MY Web Site" WebAppPool="MyWebSite_AppPool" 

                           ScriptTimeout="360" />
       <iis:WebDirProperties Id="MyWebSite_Properties" AnonymousAccess="yes" WindowsAuthentication="no" 

              DefaultDocuments="Default.aspx" />
  </iis:WebSite>
</Component>

Most of the elements and their attributes in this component are self descriptive.

<Util:User/> define the domain user which can be referenced anywhere in the source file using the Id MyWebSite_AppPoolUser.

<iis:WebAppPool/> creates the application pool with the name MyWebSiteApplication. The attribute Identity = “Other” specifies that this application pool uses Custom account for identity. And the user attribute specifies the ID of the domain\username created anywhere in the source file using <Util:User/>

<iis:WebSite/> and its child elements <iis:WebAddress/>, <iis:WebApplication/> and <iis:WebDirProperties/> define the complete web site in IIS. The Directory attribute of Web Site element is set to INSTALLLOCATION i.e. C:\Program Files\MyWebSite\ which is our target location to copy the compiled ASP.NET files to run our Web Site.

The bindings IP, PORT and Host Header for our web site are specified by <iis:WebAddress/> element, and the mapping between the application pool MyWebSite_AppPool and the site is defined by <iis:WebApplication/> . The Default Dcoument and the Authentication are specified by <iis:WebDirProperties/>.

So we have defined all the components (MySite_root_Files, MySite_bin_Directory, and MyWebSite_IISConfigure) that need to be installed on to the target server by our installer. But we know that every installer needs at least one feature which is a set of components that define one complete install feature i.e. our Web Site in this case. We have to define it using the feature element.

  <Feature Id="ProductFeature" Title="My WebSite" Level="1">
     <!-- add the components comprise of this feature -->
     <ComponentRef Id="MySite_root_Files"/>
     <ComponentRef Id="MySite_bin_Files"/>
     <ComponentRef Id="MyWebSite_IISConfigure"/>
  </Feature>

That is it. We have completed authoring the installer package for our Web Site. Upon building the entire solution again our Set up project reads the compiled ASP.NET files from our Web Deployment Project out put folder and embeds them into a Windows Installer package which is created in the out put directory of our setup project.

Fig 5: Installer package in Setup project output location

We just need to copy this installer package to the target server and double click and wait for the job to be done.

Fig 6: while installing our setup file

Once the install is complete, open the IIS Manager to see that our web site running.

Summary:

The web deployment using WIX is simple, flexible, and gives a overall great web deployment experience.

Hope this gives you a start-up point

ESTUDIO DE PROYECTOS SIMILARES Y DOCUMENTACIÓN. DECISIÓN SOBRE PLATAFORMAS. REVISIÓN DE SINOPSIS.

Grupo 1: Vancouver 2010
Grupo 2: La cerveza en España
Grupo 3: Puntos de mira
Grupo 4: Un proyecto de futuro
Grupo 5: D.O. Navarrico
Grupo 6: Moda en los 90
Grupo 7: Rock in Río Madrid 2010

1) Coordinador:

• Revisa el planteamiento del proyecto con el profesor y traslada al grupo los comentarios y la nota.
• Elabora el calendario de trabajo del grupo detallando las tareas y sus fechas de finalización.
• Revisa la primera versión de la ficha de planteamiento | Project form y la actualiza en el blog. Para ello, deberá coordinarse con el resto de compañeros y recopilar los materiales escritos por ellos en el blog.

2) Área técnica y artística:

Se prueban las distintas plataformas sugeridas: Google Sites, Jimdo, WordPress, Weebly y Wix.  En la ficha de planteamiento debe indicarse la URL de cada prueba. En el blog debe escribirse un post con las características de la plataforma elegida y debe explicarse por qué se ajusta al tipo de proyecto en marcha.

3) Área de redacción:

3.1) Se localizan 10 webs de contenido similar al proyecto y se escribe un post comentando las cuestiones relevantes de cada una de ellas para tenerlas en cuenta en el proyecto.

3.2.) Se elabora una lista exhaustiva de fuentes de dónde puede obtenerse información y se publica en un post con los comentarios pertinentes.

4) Área artística:

Se localizan objetos multimedia con el tipo de licencia que permita usarlos (Creative Commons licenses).  Abrir cuentas en Flickr y YouTube para ir almacenando allí los objetos encontrados. Escribir un post indicando las URLs y comentando a los compañeros los materiales que se van seleccionando y para que pueden emplearse. No debe olvidarse apuntar la autoría de cada imagen ya que ese dato deberá estar en el proyecto.

The first thing to do is create a name for your brand new empire. Before you get to excited, you need to check if it already exists by typing the name and trying every possible ending (e.g. com, .co.uk, .nr, .net, .gov, .org). When you are sure that your name doesn’t exist then it is time to start creating!

First you need to find a secure and professional web hosting website. Here are some good websites:

1. http://www.yola.com/
2. http://www.webs.com/
3. http://www.moonfruit.com/
4. http://www.wix.com/

When you have decided what website you want to use (it doesn’t necessarily have to be any I have selected) you can now start to build your site. It should be easy considering their main aim is to make it simple for you to make a website. When you are finished you need to publish it. Whenever you add something new to your website, update your fans by creating a blog. But remember, always update your site when you add something new.

If you want to take your website to the next level (you may have noticed that your site has the website you made it on at the end) then you can pay to have your own domain name.

What’s that?

It’s a website without the website you made it on at the end of it (e.g. www.example-of-a-domain-name.com)

Once your empire starts growing, you’ll want to grow with it so create a logo. An excelent website to make this on is:

http://www.picnik.com/

I made a Flash site for this place on Wix.com. It’s very complicated (from the “creation” side), and it’s not too good right now. There’s a comments box, contact form, a RSS feed reader for ryan(s)pace, and more to come in the near future. You can visit the Flash site at www.mainspace.tk.

Ryan

I recently converted several installers from VS.net to WiX.  In one of those installers, I was using a Registry Search condition to check to see if MSXML6 was installed, since the application requires it.  If it wasn’t installed, I was using Visual Studio’s InstallURL property to redirect the user to the Microsoft download page for the package so they could download and install it.

WiX doesn’t appear to have an InstallURL property available by default, but you can simulate it with some custom actions.   Along the way I learned quite a bit about how WiX structures CustomActions, and experienced quite a bit of frustration getting it to work.  The first step to simulating the InstallURL capability is to set up a Property that searches the registry for the MSXML key:

<Property Id="MSXML6">
    <RegistrySearch Id="MSXML6Search" Root="HKCR" Key="Msxml2.DOMDocument.6.0" Type="raw" /
</Property>

This code is very standard code for polling a registry value – no surprises here.  The next step is to build in two custom actions that both tie to this property:

<Property Id="cmd" Value="cmd.exe" />
<CustomAction Id="OpenMSXML6Download" Property="cmd"
    ExeCommand="/c start http://www.microsoft.com/downloads/details.aspx?FamilyID=993c0bcf-3bcf-4009-be21-27e85e1857b1"
    Execute="oncePerProcess"
    Return="check" />
<CustomAction Id="OpenMSXML6DownloadError" Error="MSXML6 must be installed first." />

The first Custom Action executes a command window, and starts the URL in the ExeCommand.  The important and confusing thing to note here is that the actual command to execute is put in a property, and any parameters are put in “ExeCommand” which is very poorly named.  The parameters in this case are a trick to start up the default browser to the desired URL.  The minor drawback to this is that you see the command window briefly.  I think there is a better way to do this that I’ve seen but not yet tried that involves doing a registry search to locate the default browser executable and then calling it directly.

The second custom action simply opens an Error dialog and exits the installation.

The third piece to this puzzle is to insert the Custom Action into the InstallExecuteSequence:

<InstallExecuteSequence>
    <!-- Takes user to MSXML6 download page to be installed -->
    <Custom Action="OpenMSXML6Download" After="AppSearch">NOT MSXML6 AND Not Installed</Custom>
    <Custom Action="OpenMSXML6DownloadError" After="OpenMSXML6Download">NOT MSXML6 AND Not Installed</Custom>
</InstallExecuteSequence>

One critical piece of information here is to note the “After=AppSearch”.  When I was first trying to get this to work, I dealt with an huge amount of frustration because I had set this to “After=FindRelatedProducts”.  I had chosen this because although I don’t show it above, this particular WiX install also enables the app to install over itself and prevents downgrading, and in that scenario, that’s the After value that you use.  My assumption that it would work to simulate the InstallURL was a very bad one.  The problem is that FindRelatedProducts occurs before AppSearch, which is where the RegistrySearch property is evaluated.  As a result, the MSXML6 property was NEVER defined and I was redirecting to the download page even if MSXML6 was installed.  (BTW this is a good reason to download and install the Windows SDK tools – I only discovered this because I bothered to open the MSI in Orca!)

With these three pieces in place, the installer now correctly detects MSXML6 and will redirect the user to the download page (and terminate) if it isn’t installed.  Note, however, that as presented above, the user may have to go thru the majority of the UI install before this happens.  If you don’t want the user to see any of the UI before the check and redirect takes place, duplicate the InstallExecuteSequence lines into the InstallUISequence section of the WXS file.  I’ve been told it’s somewhat of a bad practice, but that does fall more in line with the way the Visual Studio InstallURL works.

Depois de muitos meses a pensar no assunto, posso informar que o website oficial das Aventuras do Príncipe Ziph já se encontra online em http://www.ziphcomics.net .
Ainda falta completar muitas secções mas a partir de hoje podem ir espreitando o local, pois em breve irei colocar por lá não apenas tudo o que se relaciona com o historial do projecto, mas também muitos icones, wallpapers e video tutorials sobre banda desenhada.
Espalhem o link pois agradeço toda a publicidade.

–//–

After many months thinking about it, i can now say that the oficial website for The Adventures of Prince Ziph is back online at http://www.ziphcomics.net .
Altough at this time is still a bit incomplete, soon you´ll be able to read the english version of the story, download the free pdf, get wallpapers and icons and see some video tutorials about my method of drawing and painting comics.
So please spread my link around and visit often.

Today, October 14, I realized I wanted to make an entry on cows… So here it goes:

Cows have 4 legs and are interesting creatu-

After 5 minutes of thinking I realized that there’s not a whole lot I can say about cows so I abandoned the idea like Michael Jackson abandoned his dignity when he did the crotch grab:

Today, after giving up on writing about cows, I decided to make my own website. The answer is yes. Yes, there is a difference between a blog and a website. A blog is like a journal, whereas a website is updated less often and is more, beautiful and can be more customizable. The idea is to destroy the quirky “works” page on my blog, and just put a link to my official website. I tried different website-creating websites (sounds weird) I realized that webs.com is for 40-year-old stay at home moms that think it’s fun to upload pictures of their children and think it’s cool (it’s not very different from my own sight though). Later today I finished my site, here it is: my website. (huyke.co.cc)

I officially decided to make a website about me, my art, my cooking, and any other project that may come along. Here is the site so far, it is still a work-in-progress. You can also get smaller updates on my twitter

Wix.com – Ideas For Real Estate Pro

Wix.com hosts Flash and Fancy Modern Day Websites. You can create a user name, setup custom websites and web pages, then access them anytime or anywhere from the internet.  The user interface is very user friendly, and you won’t need any software of HTML experience.  This is a great solution for those of you having to use other web editors which can only be run from your desktop computers.

Build a website in 2 minutes

Some of the possibilities that have yet to be explored using WIX might include these:

• • • Creating Listings By Address
    • Open House Templates
    • Listing and Sales Presentations
    • Marketing Campaigns
    • Advertising and Promotions
    • Custom Created Market Reports
    • Mapping and Relocation Tool
    • Niche Property or Neighborhoods
    • Homeowners Associations
    • Groups and Local Events

There are endless ways that you could creatively use Wix. You can create individual, independent  sites for each of these.  You probably have even more ideas now that you’ve seen it.

It’s FREE, they host it on their site. You can sent links to anyone you want with your new Library of Tools and Sites just sitting out on the web waiting to be seen by your next clients. You can edit and customize them on the go.

Here’s a sample of what Alisa Fedele has done with WIX. Very well done, and easier than it looks or than you may think.  Here’s 7 tips to get Google SEO faster according to the Wix Blog.  The site Rocks and should at least be checked out by Industry Professionals to see if what Wix has to offer, just might be the right tools for them.

I recently had to create an installer for a service I was creating for a client.  Normally, I like to post successes and how I got past the hurdles that go me to success, but this time, I am relegated to posting a problem.  I am not trying to do much in the way of complexity and unfortunately, the WiX 3.0 Documentation is lacking.

I am trying to create an MSMQ Queue that my service will use after deployment.  There is some decent documentation about what parameters are needed to accomplish this here.  The installation actually is pretty smooth.  I have the following Component:

<MSMQ:MessageQueue
  Id="PMO.Queue"
  Label="PMO"
  PathName=".\Private$\pmo"
  Transactional="no"
  PrivLevel="none">

  <MSMQ:MessageQueuePermission 
    User="ServiceAccount"
    QueueGenericAll="yes"
    DeleteQueue="yes" 
    WriteMessage="yes"
    ReceiveMessage="yes"
    TakeQueueOwnership="yes"
    Id="Queue.Permissions.PMO"/>

</MSMQ:MessageQueue>

The problem comes when I try to uninstall the service.  Mind you that once I try to build the MSI from Visual Studio that I break compatibility with the old MSI that has been installed.  So, make sure to make backups of successfully installed MSIs otherwise you will be digging through the depths of <RootDrive>:\Windows\Installer\*.MSI trying to find the right one.

Looking at my MSI log, I see the following:

MSI (s) (98:1C) [11:19:07:524]: Invoking remote custom
   action. DLL: C:\WINDOWS\Installer\MSI54D.tmp, 
   Entrypoint:  MessageQueuingExecuteUninstall
   MessageQueuingExecuteUninstall:  Error 0×80070534:
   Failed to lookup account names MessageQueuingExecuteUninstall:  Error 0×80070534:
   Failed to get SID for account name MessageQueuingExecuteUninstall:  Error 0×80070534:
   Failed to remove message queue permission MessageQueuingExecuteUninstall:  Error 0×80070534:
   Failed to remove message queue permissions

Something that struck me was the “User” attribute on the MessageQueuePermission element.  The documentation says this should be a string.  Based on my experience with configuring IIS settings with WiX, I assumed this should be a <User /> element referencing the ID of that <User/> account.  So, I have created:

<Util:User 
  Domain="[DOMAIN]"
  Name="[ACCOUNT]"
  Password="[PASSWORD]"
  Id="ServiceAccount">
</Util:User>

To no avail.  I am going to continue researching this problem to see what I can come up with…

I build a development machine at least once a year, either on my laptop or desktop. It often takes at least a full day and is a huge time sink. I have come up with a build order for building a development machine quickly, securely, and without delays. The machine must be connected to the internet. Much of the software is available free on the web. The rest is available through the BizSpark program (also free, initially).

Here is my my current list. All of this software is publicly available, although some may be beta or research.

Windows 7 x64

Security

1. Windows Update – Run this over and over again until it says no more updates.

RESTART

2. Avast Home Edition (free anti-virus)

RESTART

3. Web of Trust

4. Spybot Search and Destroy (free anti-spyware)

 Development

5. Sql Server 2008 Developer Edition (from DVD)

6. SQL Server 2008 SP1 – Required on Windows 7

RESTART

7. Visual Studio 2008 Team Suite (from DVD)

8. Visual Studio 2008 SP1

9. Web Platform Installer – A single installer for all of these tools and more.

    A. ASP.NET MVC 1.0

    B. Silverlight Tools for Visual Studio

    C. SQL Server 2008 Express

10. Expression Studio 3 (DVD)

11. Pex – Automated White box Testing for .NET (Microsoft Research Pre-Release)

12. Windows Installer XML (Wix)

Document / Web Apps / More

13. Microsoft Office 2007 (from DVD) -OR- Microsoft Word Viewer

14. Adobe Flash Player

15. Adobe Reader

16. Outlook Connector – Recieve Live Hotmail emails in Outlook.

17. Windows Mobile Device Center – for syncing my Blackjack.

18. Zune Software - To sync music to my Zune.

J’ai créé un site où se retrouverons mes compos. Un genre de site officiel, quoi ! Voici le lien :

wix.com/juliegagne/juliegagne

Créer un site avec la plateforme Wix, c’est comme un mélange de Piczo et WordPress. Avec un compte, on peut créer des centaines, voir des milliers de sites, avec pleins de thèmes… modifiables ! On peut même commencer à zéro. J’adore !

J’ai commencé une nouvelle compo qui devrait être terminée ce soir, ou demain… au plus tard vendredi, tiens ! J’ai décidé de me lancer un défi : écrire un solo de bass. Personnellement, je m’impressionne toujours de plus en plus. Je me dis plus souvent “HOLY SCHNAUZER ! C’est vraiment moi qui a écrit ça ? Débile !”

Bon, j’vous laisse parce que j’ai trop de chose à faire… comme faire mes devoirs, trouver des infos sur les sorcières de Salem, colorier l’Afrique (sans commentaire), pratiquer ma diction avec un bouchon de liège, pratiquer mes accords, ma lecture à vue et… me préparer mentalement pour mon premier cours de solfège… :S

Check out this Demo site i made advertising Abercrombie .

http://www.wix.com/iketuonye/Abercrombie

Check Out This Flash (mini) Website i made for Hollister clothing Using wix.

http://www.wix.com/Modelco/Hollister

Whenever Windows Installer’s built-in actions do not suffice to perform a specific task, a Custom Action needs to be written. Needless to say, Custom Actions, can be a bit tricky — not only can they be laborious to write and cumbersome to debug, they also run the risk of interfering with Windows Installer’s declarative, transactional way of performing installs.

It is not really surprising that Windows Installer therefore more or less discourages the use of Custom Actions unless it is absolutely necessary. Moreover, as a result of its declarative nature, it is understadable that Windows Installer prefers Custom Actions to be data-driven.

What this means in practice is that a Custom Action should not perform a hard-coded task — rather, it should query one or more (custom) tables containing the necessary information (in a declarative manner) about what is to be performed and should act accordingly.

Using WiX, creating custom tables turns out to be pretty easy. Let’s assume we create a Custom Action that, based on some condition, does something with a specific file. An appropriate table could look like this:

<CustomTable Id="MyCustomTable">
  <Column Id="Id" Type="string" PrimaryKey="yes"/>
  <Column Id="Path" Type="string"/>
  <Column Id="Condition" Type="string"/>

  <Row>
    <Data Column="Id">Foo</Data>
    <Data Column="Path">[INSTALLLOCATION]foo.txt</Data>
    <Data Column="Condition"><![CDATA[ &FeatureFoo=3 ]]></Data>
  </Row>
  <Row>
    <Data Column="Id">Bar</Data>
    <Data Column="Path">[INSTALLLOCATION]bar.txt</Data>
    <Data Column="Condition"><![CDATA[ &FeatureBar=3 ]]></Data>
  </Row>
</CustomTable>

To query this table, we have to open a view and fetch the records one by one:

PMSIHANDLE Database = MsiGetActiveDatabase( InstallHandle );
ASSERT( Database != NULL );

PMSIHANDLE View;
UINT Result = MsiDatabaseOpenView(
  Database,
  L"SELECT `Condition`, `Path`, FROM `MyCustomTable`",
  &View );
if ( ERROR_SUCCESS != Result )
{
  ...
}

Result = MsiViewExecute( View, NULL );
if ( ERROR_SUCCESS != Result )
{
  ...
}

for ( ;; )
{
  PMSIHANDLE Record;
  Result = MsiViewFetch( View, &Record );
  if ( Result == ERROR_NO_MORE_ITEMS  )
  {
    break;
  }
  else if ( ERROR_SUCCESS != Result )
  {
    ...
  }

  //
  // Read condition.
  //
  // N.B. Do not format -- this is done by
  // MsiEvaluateCondition itself.
  //

  WCHAR Condition[ 256 ];
  DWORD Length = _countof( Condition );
  Result = MsiRecordGetString(
    Record,
    1,
    Condition,
    &Length );
  if ( ERROR_SUCCESS != Result )
  {
    ...
  }

  if ( MSICONDITION_TRUE != MsiEvaluateCondition(
    InstallHandle,
    Condition ) )
  {
    //
    // This record can be skipped.
    //
    continue;
  }

  //
  // Read remaing fields.
  //

  WCHAR Path[ MAX_PATH ];
  Length = _countof( VszPath );
  Result = GetFormattedRecord(
    InstallHandle,
    Record,
    2,
    Path,
    &Length );
  if ( ERROR_SUCCESS != Result )
  {
    ...
  }

  ...
}

With GetFormattedRecord being the following utility routine:

static UINT GetFormattedRecord(
  __in MSIHANDLE InstallHandle,
  __in MSIHANDLE Record,
  __in UINT Field,
  __out PWSTR Value,
  __inout PDWORD Length
  )
{
  DWORD RecLength = *Length;
  UINT Result = MsiRecordGetString(
    Record,
    Field,
    Value,
    &RecLength );
  if ( ERROR_SUCCESS != Result )
  {
    *Length = RecLength;
    return Result;
  }

  PMSIHANDLE FormattingRecord = MsiCreateRecord( 1 );

  Result = MsiRecordSetString( FormattingRecord, 0, Value );
  if ( ERROR_SUCCESS != Result )
  {
    return Result;
  }

  return MsiFormatRecord(
    InstallHandle,
    FormattingRecord,
    Value,
    Length );
}

Some things are worth noting:

• I use PMSIHANDLE, which, as you probably already know, is not a typedef for MSIHANDLE* but rather a smart-pointer like class that automatically closes the handle when it goes out of scope.
• The use of backticks in the query.
• It must have been a Visual Basic programmer implementing MsiRecordGetString: Field Indexes start with 1, not 0. To make matters worse, reading from index 0 does not fail but returns arbitrary data. Finally, to confuse people further, indexes are 0-based for MsiRecordSetString.
• If the field contains formatted data, you have to MsiFormatRecord it yourself. For conditions, however, MsiEvaluateCondition handles that for you.

So far, so good. There is, however, one thing to notice: To access the installer database, the custom action must be a nondeferred action:

You cannot access the current installer session or all property data from a deferred execution custom action

The problem with nondeferred actions, however, is that they execute in user context — in contrast to deferred actions, which execute in system context. On pre-Vista platforms, a per-machine installer package can be expected to always be launched by an administrator (otherwise it will fail anyway) — in this case, the differences between user and system context may not be important — both, for example, have r/w access to files in %ProgramFiles%. On Vista and later OS, however, it is common to have a regular user launch an installation which causes an elevation prompt once it reaches the main install phase. In this case, the user context is significantly less privileged than system context.

For a hypothetical custom action that is intended to edit a file installed to %ProgramFiles%, this means that (disregarding rollback considerations and assuming proper scheduling) performing this action from within the nondeferred custom action will work fine on pre-Vista OS. When run on Vista, though, it is likely to fail due to lack of write access to %ProgramFiles%. In practice, this means that all system-changing tasks usually have to be performed by a deferred action.

To sum up: To be data-driven, you have to use nondeferred actions. To be able to perform any serious, system state-changing tasks, however, you have to use deferred actions.

Great.

As it turns out, however, there is a way to escape this catch-22, and it is carefully buried in the Windows Installer documentation:

[...] Actions that update the system, such as the InstallFiles and WriteRegistryValues actions, cannot be run by calling MsiDoAction. The exception to this rule is if MsiDoAction is called from a custom action that is scheduled in the InstallExecuteSequence table between the InstallInitialize and InstallFinalize actions. [...]

[From the Remarks section of MsiDoAction]

In fact, the way I came across this solution was by looking at the source code of the WiX XmlFile action, which I knew manages to both be data-driven (uses a custom table) and alter system state (edits XML files). The way it does this, and the point where the above remark comes into play, is as follows: In the nondeferred action, you do not perform any actions changing system state. Rather, you collect the information from the installer tables and stuff it (yuck) into the CustomActionData property. Then, leveraging MsiDoAction and passing said CustomActionData, you schedule another custom action — this time a deferred one — which parses the CustomActioData (yuck) and, based on this data, finally performs the actual modifications — in system context.

It really could not be easier and more intuitive, right?

Hey-lo! If you know me well, you know that I typically get bored EASY. Yes, I am a victim of ADHD. We are hard at work, trying to find a cure…..Well, when I do get bored, I usually have three options:

A.) Bake brownies, cookies, and lemon bars until I can bake no more.
B.) Start some insane project, like making a magazine, newsletter/newspaper, or book
C.) Make a totally theme based website, which leads me to making MORE websites.

So what do you think I did today? Did you choose A? FAIL. B? EPIC FAIL. C? FA–Wait, did you say “C?” OMIGOODNESS! YOU JUST WON A MILLION DOLLARS! RAIN THE CONFETTI! YAY!!! YAY!!! YAY!!! Hold on–oops, I just recieved information that you don’t have enough insurance to get excited and faint, so you did NOT win a million dollars….But you are correct. I have made a website: www.wix.com/catherineeng/home. It’s ridiculously awesome. I have put lots of typing, and clicking, and pasting into it, so please visit it! Ugh, I’m tired. I’m gonna take a nap. Why? Because I’m an avid nap-taker. Night.

Joi Geen!

-Catherine