votive, wix, vsip, and all things microsofthttps://blogs.msdn.microsoft.com/jrock
Justin Rockwood's blogWed, 30 Jul 2008 03:17:07 +0000en-UShourly1Just upgraded to Verizon FiOS from Comcast Blasthttps://blogs.msdn.microsoft.com/jrock/2008/07/30/just-upgraded-to-verizon-fios-from-comcast-blast/
https://blogs.msdn.microsoft.com/jrock/2008/07/30/just-upgraded-to-verizon-fios-from-comcast-blast/#commentsWed, 30 Jul 2008 03:17:07 +0000https://blogs.msdn.microsoft.com/jrock/2008/07/30/just-upgraded-to-verizon-fios-from-comcast-blast/I’ve been using Comcast PowerBoost (6Mbps download / 768 Kbs upload) for about a year and have been pretty happy with it. The speed was fine and the price was good at $33/month. (Although I had to keep calling to get them to lower the price after the promotional price kept expiring). Comcast recently upgraded my neighborhood to fiber optic and so the new Blast service was available. I called them up and they just flipped a switch internally to unlock the higher speeds. I was getting roughly 12.5 Mbs download and 3 Mbs upload. The advertised rate was supposed to be 16/2, but I never got more than about 12.5. The upload was faster than advertised, though.

Well, Verizon also upgraded our neighborhood with fiber optic cabling, so I was also able to get their new FiOS service. It was cheaper for a faster rate especially since I already have my phone service with them, so I thought I’d give it a try. The installation went pretty smoothly, although it takes a while because they actually bring fiber optic cabling right to your house. It just worked, though, which is great. The speed is exactly what they’re advertising – I’m getting just barely under 20Mbs download and 5.5Mbs upload (advertised was 20/5). Blazing fast and it’s much faster than the Comcast Burst service.

Here are my speed test results using Comcast Burst…

And with Verizon FiOS…

]]>https://blogs.msdn.microsoft.com/jrock/2008/07/30/just-upgraded-to-verizon-fios-from-comcast-blast/feed/4Script# wins a Microsoft Engineering Excellence awardhttps://blogs.msdn.microsoft.com/jrock/2008/06/05/script-wins-a-microsoft-engineering-excellence-award/
https://blogs.msdn.microsoft.com/jrock/2008/06/05/script-wins-a-microsoft-engineering-excellence-award/#respondThu, 05 Jun 2008 21:06:00 +0000https://blogs.msdn.microsoft.com/jrock/2008/06/05/script-wins-a-microsoft-engineering-excellence-award/I’ve been using Script# professionally for more than a year now and am also on the Script# virtual team here at Microsoft. It’s nice to see Microsoft awarding an Engineering Excellence award to Script#.

https://blogs.msdn.microsoft.com/jrock/2008/06/05/script-wins-a-microsoft-engineering-excellence-award/feed/0How to escape a leading # within the C preprocessorhttps://blogs.msdn.microsoft.com/jrock/2008/04/22/how-to-escape-a-leading-within-the-c-preprocessor/
https://blogs.msdn.microsoft.com/jrock/2008/04/22/how-to-escape-a-leading-within-the-c-preprocessor/#commentsTue, 22 Apr 2008 17:33:06 +0000https://blogs.msdn.microsoft.com/jrock/2008/04/22/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:

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

]]>https://blogs.msdn.microsoft.com/jrock/2008/04/22/how-to-escape-a-leading-within-the-c-preprocessor/feed/2Changing the file extension of WiX extensions from .dll to .wixext (Revisited)https://blogs.msdn.microsoft.com/jrock/2008/03/03/changing-the-file-extension-of-wix-extensions-from-dll-to-wixext-revisited/
https://blogs.msdn.microsoft.com/jrock/2008/03/03/changing-the-file-extension-of-wix-extensions-from-dll-to-wixext-revisited/#commentsMon, 03 Mar 2008 15:27:57 +0000https://blogs.msdn.microsoft.com/jrock/2008/03/03/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.

]]>https://blogs.msdn.microsoft.com/jrock/2008/03/03/changing-the-file-extension-of-wix-extensions-from-dll-to-wixext-revisited/feed/5Hilarious video about what it’s like to work here at Microsofthttps://blogs.msdn.microsoft.com/jrock/2008/02/13/hilarious-video-about-what-its-like-to-work-here-at-microsoft/
https://blogs.msdn.microsoft.com/jrock/2008/02/13/hilarious-video-about-what-its-like-to-work-here-at-microsoft/#respondWed, 13 Feb 2008 18:13:00 +0000https://blogs.msdn.microsoft.com/jrock/2008/02/13/hilarious-video-about-what-its-like-to-work-here-at-microsoft/

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.

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.

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:

Right-click on the References node of the project in the Solution Explorer and choose Add Reference…

In the Add WiX Library Reference dialog, click on the Projects tab.

Select the desired project(s) and click the Add button, then click OK to dismiss the dialog.

Example

]]>https://blogs.msdn.microsoft.com/jrock/2008/01/29/complete-list-of-candle-preprocessor-variables/feed/8This is one way for Google to make Microsoft look bad…https://blogs.msdn.microsoft.com/jrock/2007/12/22/this-is-one-way-for-google-to-make-microsoft-look-bad/
https://blogs.msdn.microsoft.com/jrock/2007/12/22/this-is-one-way-for-google-to-make-microsoft-look-bad/#commentsSat, 22 Dec 2007 02:32:00 +0000https://blogs.msdn.microsoft.com/jrock/2007/12/22/this-is-one-way-for-google-to-make-microsoft-look-bad/

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:

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

Right-click on the WiX project in the Visual Studio solution explorer and select Add Reference…

In the Add WiX Library Reference dialog, click on the Browse tab and browse to the WiX extension DLL that you want to include.

Click the Add button to add a reference to the chosen extension DLL.

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:

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: