Time sure does fly... it seems like just yesterday I bought my Gateway MX6920 and started a new job. I suddenly remembered that my Vista RC2 will be expiring 5/31/2007.
So I'm trying to decide whether I should go back to XP MCE that came with my laptop or upgrade to Vista Home Premium.
But there is one thing I sure don't get. Why is it more expensive to buy direct from Microsoft via Digital Locker then it is to just go to Best Buy and pick up a copy. For that matter, Microsoft lists vendors on their website that are $45 cheaper then doing a digital download and of course I can go to Frys and pick up a system builder copy for even cheaper.
Historical archive 2003-2016
Saturday, May 26, 2007
Friday, May 25, 2007
IS SABLD should be free
I originally meant to write about this blog 6 months ago. However, for some reason it ended up in my drafts list never to bubble up again until now.
I really wish that Macrovision would release the InstallShield Stand Alone Build Engine without any licensing restrictions or with some type of resellers program. I think this would be inline with Microsoft's MSBuild technology.
When I engage with potential clients, I frequently encounter customers who want to outsource their small installs but they are afraid to go with InstallShield because of the initial tools investment. They will actually go down the path of reinventing the wheel with lesser tools because of their understimating of the amount of work involved.
The reality is that these customers typically only need to be able to build their project, `own` their source as a work for hire and occasionaly bring in an outside consultant for maintenance without the full blown expense of InstallShield.
I really wish that Macrovision would release the InstallShield Stand Alone Build Engine without any licensing restrictions or with some type of resellers program. I think this would be inline with Microsoft's MSBuild technology.
When I engage with potential clients, I frequently encounter customers who want to outsource their small installs but they are afraid to go with InstallShield because of the initial tools investment. They will actually go down the path of reinventing the wheel with lesser tools because of their understimating of the amount of work involved.
The reality is that these customers typically only need to be able to build their project, `own` their source as a work for hire and occasionaly bring in an outside consultant for maintenance without the full blown expense of InstallShield.
Wednesday, May 23, 2007
TIP: Parallel IS12/2008 Builds Using TFS
So let's say your rolling with TFS/MSBuild using VS2005 solution integration and everything is building just fine. Suddenly a new version of InstallShield comes out.
Your really curious to try it out but your afraid of introducing instability to your production builds. Try this.... Parallel Builds.
InstallShield Stand Alone Build can be installed safely side by side. Install the latest SAB on your build box ( or bring up another build box with SAB 2008 )
Branch the project contain your .SLN/.ISPROJ/.ISM. In the branch, checkout the .ISPROJ file and modify the Import Project statment to point to $(MSBuildExtensionsPath)\Macrovision\IS2008\Macrovision.InstallShield.targets.
Go to TeamBuildTypes and clone your build type to a new name. For example Client becomes Client-2008. Update the workspacemappings.xml to point to your new branch in TFS source control. Modifiy your newly cloned TFSBuild.proj and update the DropLocation property aswell as the Description and BuildMachine ( if changed ) project extensions.
Finally check it all in and do a build. If you did it right, your build should run like always but in a seperate build space, use the new SAB 2008, automatically upgrade the ISM source to 2008 schema and drop the build in your archives in a side by side location.
Now you can safely regression test your installation without committing to using IS2008 since your project source is still in IS12 format. If you make changes to your project, just merge them to the 2008 branch and rebuild. When you are confident that everything is good to go you can update the .ISPROJ file on your main branch and start doing dev using IS2008.
TFS and InstallShield just makes it too easy...
Your really curious to try it out but your afraid of introducing instability to your production builds. Try this.... Parallel Builds.
InstallShield Stand Alone Build can be installed safely side by side. Install the latest SAB on your build box ( or bring up another build box with SAB 2008 )
Branch the project contain your .SLN/.ISPROJ/.ISM. In the branch, checkout the .ISPROJ file and modify the Import Project statment to point to $(MSBuildExtensionsPath)\Macrovision\IS2008\Macrovision.InstallShield.targets.
Go to TeamBuildTypes and clone your build type to a new name. For example Client becomes Client-2008. Update the workspacemappings.xml to point to your new branch in TFS source control. Modifiy your newly cloned TFSBuild.proj and update the DropLocation property aswell as the Description and BuildMachine ( if changed ) project extensions.
Finally check it all in and do a build. If you did it right, your build should run like always but in a seperate build space, use the new SAB 2008, automatically upgrade the ISM source to 2008 schema and drop the build in your archives in a side by side location.
Now you can safely regression test your installation without committing to using IS2008 since your project source is still in IS12 format. If you make changes to your project, just merge them to the 2008 branch and rebuild. When you are confident that everything is good to go you can update the .ISPROJ file on your main branch and start doing dev using IS2008.
TFS and InstallShield just makes it too easy...
InstallShield 2008 Stand Alone Build Download
InstallShield 2008 Released
I just received my InstallShield Maintenance Fulfillment notice via email. I'd love to say more but it's time to go download the real thing.
Press Release:
New Version of InstallShield Helps Tackle Complexity in Installing Programming Rich Software
Macrovision’s InstallShield 2008 Addresses New Installation Requirements For Windows Vista, Accelerating Product Time to Market
SANTA CLARA, Calif.--(BUSINESS WIRE)--Macrovision Corporation (NASDAQ: MVSN) today announced the latest edition of its installation authoring solution for Windows, InstallShield 2008. The new edition of InstallShield is designed specifically to help developers easily package and deliver advanced Windows Vista-based software programs, helping customers experience a smooth and reliable installation process. It meets the latest Microsoft platform requirements.
According to IDC, Windows Vista will be the fastest adopted version of Windows, with over 90 million copies of Windows Vista in place worldwide by the end of 20071. As developers ramp up software programming to meet demands from businesses eager to switch to Windows Vista, they will require a solution that will help them become more proficient in creating installation for their software programs.
InstallShield 2008 features a new digital signing tab that eliminates the hassle of signing executable files individually. It also includes the ability to help validate Microsoft Software Installers (MSIs) as per the Certified for Windows Vista Logo program requirements. These and the other features included in InstallShield 2008 help simplify the complex process of creating effective installations for software programs in today’s digital economy.
“With tools that help software vendors create setup MSIs that are compliant with the Certified for Windows Vista installation requirements, InstallShield 2008 gives software vendors confidence in targeting Windows Vista, by helping to accelerate and simplify the certification process,” said Tom Caputo, group product manager at Microsoft Corp. “Microsoft and Macrovision are continuously working together to help facilitate integration and compatibility, while maintaining ease of use.”
“Macrovision’s InstallShield 2008 streamlines the process of making installers for Windows Vista,” said Ken Steltzner, software engineer at M-Audio, a business unit of Avid Technology, Inc. “The new digital signing feature lets you easily sign all files in the installer package in one place, right inside InstallShield 2008. This feature makes it easier for us to meet the new installer requirements in Windows Vista.”
“For software providers to stay competitive installations have to work. There is no way around it. Software providers need to incorporate the latest installation advancements and ensure a reliable and intuitive experience installation experience,” said Corey Ferengul, senior vice president of product and solution management at Macrovision. “InstallShield 2008 enables companies to focus on developing their products by making it easier to rapidly deliver those new products on the latest Windows platforms.”
InstallShield is an industry standard for authoring high-quality Windows Installer and InstallScript installations with award-winning technology deployed on more than 500 million PCs worldwide. It is designed to ensure that software applications are correctly installed, configured, updated and eventually uninstalled on Windows -based desktops.
InstallShield 2008 is available today.
Thursday, May 17, 2007
Setup Factory for Windows Installer
I noticed over on Stefan's blog that there is another WiX UI player on the scene. I was curious so I downloaded it. Indigo Software requests that comments about the product be confined to their beta forum, and I will attempt to respect their wishes, so all I'll say right now is go check it out. I have and while it's not feature complete yet, I like what I see so far. My first 30 minutes with it have been a *MUCH* better experience then my first 30 minutes with WiXAware.
Check it out here.
I like the XML schema/compiler aspects of WiX a lot. But I've always thought that the developer tools were just absolutely horrible. I learned ANSI C using vi, cc and make on Solaris 10 years ago and I can tell you that is not the way I code today. Visual Studio 2005 has come a LONG way since those days.
Regardless, I'm finding WiX hard to ignore these days not so much because WiX has improved, but because I'm starting to get the feeling that the Windows Installer team simply will never update the core windows installer service but will instead rely on WiX to implement them in the CustomActions dll. You certainly get this impression reading the various Microsoftie blogs.
Perhaps if a few tools like this would come along and provide a really good development story it will become time for me to take the plunge.
Meanwhile, I wonder if Macrovision has been working on anything...
Check it out here.
I like the XML schema/compiler aspects of WiX a lot. But I've always thought that the developer tools were just absolutely horrible. I learned ANSI C using vi, cc and make on Solaris 10 years ago and I can tell you that is not the way I code today. Visual Studio 2005 has come a LONG way since those days.
Regardless, I'm finding WiX hard to ignore these days not so much because WiX has improved, but because I'm starting to get the feeling that the Windows Installer team simply will never update the core windows installer service but will instead rely on WiX to implement them in the CustomActions dll. You certainly get this impression reading the various Microsoftie blogs.
Perhaps if a few tools like this would come along and provide a really good development story it will become time for me to take the plunge.
Meanwhile, I wonder if Macrovision has been working on anything...
??PROJ is for MSBuild Projects
I've been really hard core into TFS and MSBuild lately.... I have to say I really love it. Unfortunatly I've been seeing something very disturbing lately....
??PROJ files should be MSBUILD documents!
Starting with VS2005, Microsoft adopted MSBuild in a major way. If you look at VS projects ( like a C# project ) you'll see that it's really an MSBuild project file that teaches MSBuild/VS how to build your C# ( .cs ) files.
WiX/Votive v3 gets it right, and InstallShield gets it right also. They each have their own MSBuild project file ( .wixproj and .isproj )and then a specific document format ( .wxs and .ism ) Congratulations WiX and InstallShield!
Unfortunatly other setup tools vendors aren't getting the message. It all started with that bastard authoring program called Visual Studio Deployment Projects. They use the .vdproj extension, but it's NOT an MSBuild file. The same goes for WiXAware and Setup Factory for Windows Installer. Both of these tools seem to think that you should put your WiX document right inside the ??proj file.
Wrong! The ??proj file is for MSbuild. The actual source code should go in a seperate source code file. In the case of WiX, it should go in a standard .wxs file with complete compatibility for the standard WiX candle/light toolset programs.
And while we are at it, Visual Studio integration is the only way to fly. Bite the bullet and support it.
This may seem trivial, but anyone who's gotten into TFS and MSBuild can tell you how much of a pain in the rear it is when your wire up a TFSBuild.proj, point it to the solution to build, add the project to the configuration manager and find out that it won't work.
??PROJ files should be MSBUILD documents!
Starting with VS2005, Microsoft adopted MSBuild in a major way. If you look at VS projects ( like a C# project ) you'll see that it's really an MSBuild project file that teaches MSBuild/VS how to build your C# ( .cs ) files.
WiX/Votive v3 gets it right, and InstallShield gets it right also. They each have their own MSBuild project file ( .wixproj and .isproj )and then a specific document format ( .wxs and .ism ) Congratulations WiX and InstallShield!
Unfortunatly other setup tools vendors aren't getting the message. It all started with that bastard authoring program called Visual Studio Deployment Projects. They use the .vdproj extension, but it's NOT an MSBuild file. The same goes for WiXAware and Setup Factory for Windows Installer. Both of these tools seem to think that you should put your WiX document right inside the ??proj file.
Wrong! The ??proj file is for MSbuild. The actual source code should go in a seperate source code file. In the case of WiX, it should go in a standard .wxs file with complete compatibility for the standard WiX candle/light toolset programs.
And while we are at it, Visual Studio integration is the only way to fly. Bite the bullet and support it.
This may seem trivial, but anyone who's gotten into TFS and MSBuild can tell you how much of a pain in the rear it is when your wire up a TFSBuild.proj, point it to the solution to build, add the project to the configuration manager and find out that it won't work.
Monday, May 14, 2007
MSVCR71.DLL TIDBIT Part II (ASP.NET behavior)
I recently posted an observation regarding the absence of msvcr71.dll from the Microsoft .NET 2.0 framework install. This causes problems when take a .NET 1.1 assembly that has a dependency on the DLL and run it on the .NET 2.0 CLR.
Naturally when mitigating this problem you want to try to deploy the DLL privately to your application instead of the .NET framework directory on the System32 directory so that you avoid potential DLL hell. Unfortunately I found another piece of trivia regarding ASP.NET.
Let's say your deploying a webservice that includes an assembly like I previously described. ASP.NET doesn't use your webservice\bin folder as the application directory, it instead copies your assemblies to a temporary folder and uses it. But it gets interesting.... ASP.NET only copies MANAGED assemblies to the folder, it leaves unmanaged dll's behind. What this basically means is that you can't really mitigate the problem in a clean way. You have to deploy the unmanaged assembly (msvcr71.dll) to the System32 folder, [WindowsFolder]Microsoft.NET\Framework\v2.0.50727 folder or even worse, another folder which you append to the system path. Yuck.
Now of course it gets even more interesting. ASP.NET will copy *ALL* managed assemblies to the temporary folder whether you actually use them or not. Your web service assembly doesn't actually have to have references to the assemblies, ASP.NET just assumes that you might be using reflection and makes them all available to you. It's just if your assemblies have dependencies on unmanaged code.... well your out of luck there.
Fortunately when it was getting really dark and ugly the ASP.NET developer tells me... `Oh, we don't use that assembly anymore anyways`. So I dropped the offending assembly from the webservice\bin folder and sure enough, everything works as expected without actually having to deploy msvcr71.dll to the System32 folder!
Naturally when mitigating this problem you want to try to deploy the DLL privately to your application instead of the .NET framework directory on the System32 directory so that you avoid potential DLL hell. Unfortunately I found another piece of trivia regarding ASP.NET.
Let's say your deploying a webservice that includes an assembly like I previously described. ASP.NET doesn't use your webservice\bin folder as the application directory, it instead copies your assemblies to a temporary folder and uses it. But it gets interesting.... ASP.NET only copies MANAGED assemblies to the folder, it leaves unmanaged dll's behind. What this basically means is that you can't really mitigate the problem in a clean way. You have to deploy the unmanaged assembly (msvcr71.dll) to the System32 folder, [WindowsFolder]Microsoft.NET\Framework\v2.0.50727 folder or even worse, another folder which you append to the system path. Yuck.
Now of course it gets even more interesting. ASP.NET will copy *ALL* managed assemblies to the temporary folder whether you actually use them or not. Your web service assembly doesn't actually have to have references to the assemblies, ASP.NET just assumes that you might be using reflection and makes them all available to you. It's just if your assemblies have dependencies on unmanaged code.... well your out of luck there.
Fortunately when it was getting really dark and ugly the ASP.NET developer tells me... `Oh, we don't use that assembly anymore anyways`. So I dropped the offending assembly from the webservice\bin folder and sure enough, everything works as expected without actually having to deploy msvcr71.dll to the System32 folder!
Friday, May 11, 2007
Wow, Roll Your Own!
In a recent thread in the microsoft.public.platformsdk.msi newsgroup, I read this gem from PLohrman:
Wow! 6 man months to write an MSI authoring tool that meets a `majority of features` we needed. Man, can you say NOT-INVENTED-HERE? Seriously, if I did this to a client it would basically cost them well over $130,000 based on my staff augmentation bill rates through my employer.
Guys, tools are cheap! Tools are fast and reliable. There are some really good case studies that show when you should decide to roll your own and when you should simply assimilate someone else's technology into your solution. If you are a company like Macrovision or InstallAware, then yes, you roll your own because that's your core business. That's your product line and your going to sell it. If your a company like Microsoft with many, many products to ship, it makes a lot of sense to roll your own because it's part of your core business. Heck, it makes even more sense if you can get a bunch of employees to write it for free on their own time!!
But if your the typical ISV or Enterprise IT department trying to author or repackage an install, think about it. Do you really want to go through 6 months pain trying to get a decent tool put together and spend $125,000 doing it? Heck, that's enough money to buy 50 copies of InstallShield 12 Professional and put them on Silver Maintenance for a year. That would be enough money to buy 325 copies of WiXAware.
Seriously, people often make fun of InstallShield ( one particular MS MVP loves to banter around the term InstallSucks or InstallCrap ). They'll call it buggy, they'll call it expensive, they'll banter around terms like `vendor lock in` or `proprietary`.... but at the end of the day the cost of one seat is only about 3 days of labor and you can start working on installation projects today, not in three months.
Call me pragmatic, but I get pride in delivering solutions to my customers, not in trying to reinvent the wheel and showing a vendor that I'm smarter then they are.
As a heads-up, I am writing a tool to generate MSI files, I worked on it consistently for about 3 months to get the functionality up to the point of being able to incorporate the majority of features we needed. I've been working for another 3 months on-and-off to fine tune the behavior and add customizations to the installations.
A good portion of that time was spent reading and understanding the database tables:
http://msdn2.microsoft.com/en-us/library/aa368259.aspx and the installer object interface:
http://msdn2.microsoft.com/en-us/library/aa369432.aspx
I didn't hear about WiX until afterwards and haven't used it, but it probably would have been wise to look at that first and then thought about building on its functionality.
Wow! 6 man months to write an MSI authoring tool that meets a `majority of features` we needed. Man, can you say NOT-INVENTED-HERE? Seriously, if I did this to a client it would basically cost them well over $130,000 based on my staff augmentation bill rates through my employer.
Guys, tools are cheap! Tools are fast and reliable. There are some really good case studies that show when you should decide to roll your own and when you should simply assimilate someone else's technology into your solution. If you are a company like Macrovision or InstallAware, then yes, you roll your own because that's your core business. That's your product line and your going to sell it. If your a company like Microsoft with many, many products to ship, it makes a lot of sense to roll your own because it's part of your core business. Heck, it makes even more sense if you can get a bunch of employees to write it for free on their own time!!
But if your the typical ISV or Enterprise IT department trying to author or repackage an install, think about it. Do you really want to go through 6 months pain trying to get a decent tool put together and spend $125,000 doing it? Heck, that's enough money to buy 50 copies of InstallShield 12 Professional and put them on Silver Maintenance for a year. That would be enough money to buy 325 copies of WiXAware.
Seriously, people often make fun of InstallShield ( one particular MS MVP loves to banter around the term InstallSucks or InstallCrap ). They'll call it buggy, they'll call it expensive, they'll banter around terms like `vendor lock in` or `proprietary`.... but at the end of the day the cost of one seat is only about 3 days of labor and you can start working on installation projects today, not in three months.
Call me pragmatic, but I get pride in delivering solutions to my customers, not in trying to reinvent the wheel and showing a vendor that I'm smarter then they are.
Thursday, May 3, 2007
Vista UAC implications of ServiceControlManager API calls
Sometimes I need to have LaunchConditions based on the installation/execution state of a service. For example a customer might require that a package only be installable if indexing service or IIS is running.
Unfortunatly, despite 8 years of development, Windows Installer *STILL* does not have extensions to the AppSearch pattern to facilitate this type of checks. It's a shame because the table extensions ( ServiceLocator ) would be really easy to implement without hurting existing installs. So basically we are forced to write `Evil` Custom Actions....... Ok, now that my overview rant is done, let's get onto something interesting:
Recently a thread on InstallShield Community got my attention. sks2004 and rguggisberg were noting that the InstallScript function ServiceExistsService() wasn't working on Vista without elevation while the SC QUERY command was working without elevation.
Upon examination I suspected and confirmed that the ServiceExistsService function was calling the OpenSCManager API function and requesting too many privledges. While I didn't have access to InstallScripts source code, I did have access to an ancient service wrapper from the InstallScript 5 days located over on InstallSite.
Sure enough, inside the source I could see the SCM initialization functions generically requesting the SC_MANAGER_ALL_ACCESS rights. The call would fail and the service would go undetected. Finally BryanWolf ( Macrovision Dev ) stepped in and confirmed the bug and advised that WO IOC-000059857 has been created. Until the issue is addressed, the work around is to request administrator elevation for the client side UI sequence or run the CA in defferred with system context. If neither of those are acceptable, I posted a modifed version of the InstallScript code on the forums.
So my two take away points are:
1) Vista Security changes continues to manifest itself in obsecure ways. You might think your doing a read-only operation but the underlying stack asks for more.
2) I really, really, really wish Windows Installer would provide support for more use cases via the standard actions. Yes I know custom actions are more evil then standard actions.... but they are completly unavoidable when the standard actions won't support the use cases that your PAYING customers require.
Unfortunatly, despite 8 years of development, Windows Installer *STILL* does not have extensions to the AppSearch pattern to facilitate this type of checks. It's a shame because the table extensions ( ServiceLocator ) would be really easy to implement without hurting existing installs. So basically we are forced to write `Evil` Custom Actions....... Ok, now that my overview rant is done, let's get onto something interesting:
Recently a thread on InstallShield Community got my attention. sks2004 and rguggisberg were noting that the InstallScript function ServiceExistsService() wasn't working on Vista without elevation while the SC QUERY command was working without elevation.
Upon examination I suspected and confirmed that the ServiceExistsService function was calling the OpenSCManager API function and requesting too many privledges. While I didn't have access to InstallScripts source code, I did have access to an ancient service wrapper from the InstallScript 5 days located over on InstallSite.
Sure enough, inside the source I could see the SCM initialization functions generically requesting the SC_MANAGER_ALL_ACCESS rights. The call would fail and the service would go undetected. Finally BryanWolf ( Macrovision Dev ) stepped in and confirmed the bug and advised that WO IOC-000059857 has been created. Until the issue is addressed, the work around is to request administrator elevation for the client side UI sequence or run the CA in defferred with system context. If neither of those are acceptable, I posted a modifed version of the InstallScript code on the forums.
So my two take away points are:
1) Vista Security changes continues to manifest itself in obsecure ways. You might think your doing a read-only operation but the underlying stack asks for more.
2) I really, really, really wish Windows Installer would provide support for more use cases via the standard actions. Yes I know custom actions are more evil then standard actions.... but they are completly unavoidable when the standard actions won't support the use cases that your PAYING customers require.
Wednesday, May 2, 2007
Labels are History
If you've followed a broken link to this site, I apologize.... it's because I've eliminated all of my labels.
Recently I've noticed that many people who read this blog get referred to an article via an indexed label that is no longer current. This means they aren't getting the content that they are expecting to find.
(Yes, this means I frequently look at the logs to try to get an understanding of who my readers are and what topics interest them. )
Frankly I'm too busy to try to understand why this is happening, but if someone is wise to the ways of Blogger.... please free to educate me. :)
Until then, I'm removing the labels and waiting for Google to re crawl this blog. Hopefully this way people will actually get the articles that they are trying to search for.
Recently I've noticed that many people who read this blog get referred to an article via an indexed label that is no longer current. This means they aren't getting the content that they are expecting to find.
(Yes, this means I frequently look at the logs to try to get an understanding of who my readers are and what topics interest them. )
Frankly I'm too busy to try to understand why this is happening, but if someone is wise to the ways of Blogger.... please free to educate me. :)
Until then, I'm removing the labels and waiting for Google to re crawl this blog. Hopefully this way people will actually get the articles that they are trying to search for.
Subscribe to:
Posts (Atom)