How to escape a leading # within the C preprocessor

This is probably a no-brainer for most people, but for some reason I banged my head against the wall for about an hour trying to figure this one out.

Background

Oftentimes you have source files (or in our case aspx files) that contain common headers, footers, sections, etc. Instead of paying the runtime hit of dynamically including things within the page, we just use the C preprocessor to #define macros that get expanded at build time. For example, do you ever get sick of writing the <!DOCTYPE> at the top of the page or want to make sure that it's consistent across all of your pages? Well, it's easy to do if you use a C preprocessor macro:

Then in your .aspx page simply do this:

and voilà.

Problem

Well, what if you have something like this in your .aspx.pp page (we use a .pp extension to indicate that it's a C preprocessor file that will get renamed after the preprocessor runs):

<style type="text/css">
#element {
background-color: white;
}
</style>


The C preprocessor will barf at you and say something like the following:

fatal error C1021: invalid preprocessor command 'element'

Solution

There are a couple different ways of fixing this, although I think the simplest way is to just define a macro that just passes through its argument, like this:

#define IGNORE_HASH(x) x

Then you change the code to this:

<style type="text/css">
IGNORE_HASH(#element) {
background-color: white;
}
</style>


Now the C preprocessor ignores the #element and everything works as expected.

Changing the file extension of WiX extensions from .dll to .wixext (Revisited)

In one of my last blog posts I wrote about how we would be changing the file extension of WiX extensions from .dll to .wixext. Well, it turns out that we won't be doing it for technical reasons.

A WiX extension is really just a .NET assembly with an embedded XSD and wixlib. While it's technically possible to rename a managed assembly from .dll to .wixext, it will add a limitation that we didn't want to enforce. If WixExtensionA.wixext had a runtime reference to WixExtensionB.wixext, then the runtime cannot find the file if it doesn't end in a .dll. I personally think that's a limitation that the .NET Framework did not need to impose, but I also do not know all of the details. I'm sure there was a good reason to impose that limitation. We also had some problems with Visual Studio not letting us add project references to other WixExtensions that didn't end in a .dll.

As a result, we will not be doing this change and the current behavior will remain.

Hilarious video about what it's like to work here at Microsoft

This is a pretty realistic video of what it's like to work here. :)

http://on10.net/blogs/tina/Life-At-Microsoft/

Changing the file extension of WiX extensions from .dll to .wixext

We will be doing a change that will probably affect most users of WiX v3, so I wanted to get this blog post out in the community to notify people of the upcoming change. Within the next few weeks we will be changing the file extension of WiX extensions from .dll to .wixext. There are several reasons why we think this is an important thing to do:

• Wix-specifc file extensions
• OS file handlers and icons
• Votive UI

WiX-specific File Extensions

Although a WiX extension is really just a .NET assembly with an embedded XSD and wixlib, it really should be differentiated as a separate file type. This gives us the flexibility to change the format of the file in the future without affecting the semantics of how you work with the file.

Also, we have WiX-specific file extensions for all of our other types of files. For example, .wxs, .wxi, and .wxl are all XML files, but giving a separate file extension provides ease of use.

OS File Handlers and Icons

Typically a file extension is handy when viewing and working with files in Windows Explorer. For example, when you double-click a .wxs file (assuming you have installed Votive), then Visual Studio will be opened and will display the contents of that file. Users are also free to associate other tools with a given file extension. The problem with using the .dll extension in our WiX extensions is that it limits our flexibility in regards to open behavior in Windows Explorer. First of all, a DLL is a special type of entity in Windows, so mapping editors/viewers to the .DLL extension is not always possible or advisable. In the future, we may want to open WiX extensions in Votive in a special type of viewer or editor. By having a separate .wixext file extension, it gives us this flexibility.

One other advantage to using .wixext is that we can associate an icon with the extension. We can't do that if we use the .DLL extension (well we can but not without writing some code to open up the file and detect whether it is truly a WiX extension).

Votive UI

In Votive, when you want to add a reference to an extension the "Add Reference" dialog will be shown. Currently it filters on WiX Extension Files (*.dll) which shows all of the standard extensions, but it also will show things like wix.dll, which aren't WiX extensions. That's a little confusing to a new user I think. Granted, we do name our extensions things like WixIIsExtension.dll, so it's at least somewhat evident, but still it's confusing. If we can instead filter on *.wixext then only valid WiX extensions are shown in the Add Reference dialog.

Backwards Compatibility

Although the file extension will change from .dll to .wixext the tools will still support the old .dll extension. In fact, they really won't impose any restriction on the file extension since the contents of the file are what matter.

How Does this Affect You?

If you use any of the standard WiX custom action extensions, then you'll have to change your build scripts to reference the new names.

If you use MSBuild or Votive, then you'll have to change any references you have in your .wixproj files (<WixExtension> elements). You can do this manually by hand-editing the .wixproj file or you can do this by removing the old references (right mouse click and select "Remove") and then re-adding them.

<ItemGroup>  
  <WixExtension Include="$(ProgramFiles)\Windows Installer XML v3\bin\WixIIsExtension.wixext" />
</ItemGroup>

We will also try to put out a similar reference for NMake and NAnt when the feature gets checked in.

The bug tracking this feature is at http://sourceforge.net/tracker/?func=detail&atid=642714&aid=1868802&group_id=105970.

We expect to have the work done and checked in by the end of February. We will send out another notice to the wix-users@lists.sourceforge.net alias and I will also post another blog entry when this happens.

Complete list of Candle preprocessor variables

Some people have asked about this in the past on the wix-users mailing list, so I thought I'd just put it here so it's on the web searches. (We really need to do an overhaul on our WiX home page).

This is just copied verbatim from the Wix.chm file.

[Edit]: By the way, this list applies to Votive v3 and not Votive v2. Although similar, complete instructions on how to do this in Votive v2 are given in Rob's MSDN article here (http://msdn2.microsoft.com/en-us/aa302186.aspx#wixsetup_topic9).

Project References

Introduction

The WiX Visual Studio package supports adding project references to a WiX project. This ensures that build order dependencies are defined correctly within the solution. In addition, it generates a set of WiX preprocessor definitions which are set on the Candle command line and can be referenced in source files.

Adding Project References

To add a project reference to a WiX project:

1. Right-click on the References node of the project in the Solution Explorer and choose Add Reference...
2. In the Add WiX Library Reference dialog, click on the Projects tab.
3. Select the desired project(s) and click the Add button, then click OK to dismiss the dialog.

List of Supported Project References

The WiX Visual Studio package supports the following project reference variables:

Example

The following File element demonstrates how to use project references in WiX authoring:

<File Id="MyExecutable" Name="$(var.MyProject.TargetFileName)" Source="$(var.MyProject.TargetPath)" DiskId="1" />

This is one way for Google to make Microsoft look bad...

I thought this was a pretty amusing blog entry (http://www.dailydoseofexcel.com/archives/2007/12/18/google-toolbar-slows-excel/). While I don't think this was intentional, it's a pretty interesting tactic: just install your plug-in to Excel to slow it down. :-)

All in good fun. I haven't used Google desktop search in a while, but I liked it when I had it, so don't read anything into this blog entry.

How to use Extensions in Votive (IIS or UI extensions, for example)

It seems we have this question pop up a few times a week on the wix-users mailing list, so I thought I'd add something here as another reference when people are searching the web. Thanks to Aaron Stebner for writing this entry in our WiX.chm file, available as part of the WiX releases (>= 3.0.3419).

How to use WiX 3.0 extensions when building MSIs

To use a WiX 3.0 extension when calling the WiX tools directly, you need to use the -ext command line parameter available in the Candle, Light and Lit tools and pass in the extension DLL(s) needed for your project. Each extension DLL must be passed in via separate -ext parameters. For example:

light.exe MySetup.wixobj
-ext "C:\Program Files\Windows Installer XML v3\bin\WixUIExtension.dll"
-ext "C:\Program Files\Windows Installer XML v3\bin\WixUtilExtension.dll"
-out MySetup.msi

To use a WiX 3.0 extension when building in Visual Studio with the Votive add-in, you can use the following steps:

1. Right-click on the WiX project in the Visual Studio solution explorer and select Add Reference...
2. In the Add WiX Library Reference dialog, click on the Browse tab and browse to the WiX extension DLL that you want to include.
3. Click the Add button to add a reference to the chosen extension DLL.
4. Browse and add other extension DLLs as needed.

After you have added a reference to an extension DLL, Votive will automatically add the appropriate -ext command line switches when it calls Candle, Light or Lit when performing a build.

How to enable IntelliSense for WiX 3.0 extensions

To enable IntelliSense for a WiX extension in the Visual Studio IDE, you must also add an XMLNS declaration to the <WIX> element in your WXS file. For example, if you want to use the NativeImage functionality in the WixNetFxExtension, the element would look like the following:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension"> 

After adding this, you can add an element named <netfx:NativeImage/> and view IntelliSense for the attributes supported by the NativeImage element.

SyncToy 1.4 and Vista 64-bit (x64) Error

I use the extremely useful SyncToy to mirror my data between various machines at home. However, it did not work on Vista x64. I found this very handy blog post which tells you how to fix the problem. I didn't feel like installing Windows Network Monitor 3.1, so I decompiled it using dark and extracted the needed file out of the msi. I'm attaching it here for anybody that's interested.

Here's an example of the error that you'll see if you have the problem:

Problem signature:
  Problem Event Name: CLR20r3
  Problem Signature 01: synctoy.exe
  Problem Signature 02: 1.4.0.0
  Problem Signature 03: 453f990b
  Problem Signature 04: SqmManagedWrapper
  Problem Signature 05: 1.4.0.0
  Problem Signature 06: 453f9909
  Problem Signature 07: 8
  Problem Signature 08: 38
  Problem Signature 09: System.BadImageFormatException
  OS Version: 6.0.6000.2.0.0.256.1
  Locale ID: 1033

Here's how to fix the problem: 

• Rename custsat.dll in the installation directory for SyncToy (C:\Users\[YourLoginName]\AppData\Local\SyncToy\ by default) to custsat.dll.original so that you can restore the file if you want.
• Copy the custsat.dll file attached to this blog post to C:\Users\[YourLoginName]\AppData\Local\SyncToy\ (or wherever you installed SyncToy).

That's it. You should be good to go now. I need to log a bug on this for the SyncToy team if one hasn't been logged already.

Excel Services is a "game changer"

Richard McAniff, one of our corporate vice presidents in Office, had some interesting stuff to say about Excel Services at the Office 2.0 Conference in San Francisco. Here's an exerpt from the blog at http://blogs.zdnet.com/BTL/?p=6149:

I later asked McAniff how he defined a “game changer.” “If you can you radically reduce cost, improve productivity and top line revenue, it’s a game changer.” He cited spreadsheets, search and eBay as examples... McAniff cited Excel Web Services as a game changer. “It satisfies end user and IT requirements. A mere mortal can publish a spreadsheet and it can go through a workflow process."

Sometimes when you're nose-down in your work you forget how cool the stuff you're working on is. It's nice to get a reminder every once in a while. :)

London Stock Exchange is Using Excel Services

Cool!

http://windowsfs.com/eNews/tabid/112/articleType/ArticleView/articleId/2073/Default.aspx

Shahar has waaay too much time on his hands :)

Check out this blog post from Shahar, one of the devs I work with.

http://blogs.msdn.com/cumgranosalis/archive/2007/08/21/code-art-like-ascii-art-only-sucks-so-much-more-to-create.aspx

Job Openings on My Team

My team (Excel Server) is currently hiring developers. It's a great team to work on and we do some cool stuff. Since we're still a fairly new team (we just shipped version 1.0 with Office Server System 2007), there's still lots and lots of new code to write and you'd have the ability to have a very impactful influence over the future of the product. Here's the "official" blurb:

Microsoft Office is looking for talented developers to work on cutting edge web-based technologies that integrate with Excel and Access. It’s a great opportunity to work on cool new features and build great products.  You may have already heard about Excel Services that we shipped with Office 2007 (if not you can read more here http://office.microsoft.com/en-us/sharepointserver/HA101054761033.aspx and here http://msdn2.microsoft.com/en-us/library/ms519581.aspx) and we’re building on that story as well as pursuing some other new ideas.

If you know someone who might be interested in the position, please contact rmcgrath@microsoft.com. For more info, check out this job listing: http://members.microsoft.com/careers/search/results.aspx?FromCP=Y&Keywords=HA101054761033

If you're interested you can either contact me directly (jrock@microsoft.com) or the address above.

New Excel Services forum on MSDN

If you ever have any Excel Services questions, feel free to use the new forum on MSDN to post your questions. We'll try to be responsive in giving out answers.

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1208&SiteID=1

It's nice to see the community responding well to Excel Services

Here's a nice article written about Excel Services:

http://www.aspnetpro.com/newsletterarticle/2006/08/asp200608ab_l/asp200608ab_l.asp

It's good to see your hard work pay off with good reviews. We'll see how the reviews are when it's "officially" released.

Handy little Visual Studio shortcut key for Wix/Votive developement

If you use Visual Studio to edit your Wix projects (either using Votive or just the plain XML editor), you may be interested in this handy little shortcut key. If you turn on pedantic checking for your WiX files, one of the warnings will be about having mixed-case GUIDs. The easy fix is to select the GUID and then go to Edit / Advanced / Make Uppercase (Ctrl+Shift+U). Voila, your GUID is now all uppercase.