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-2011
May 26, 2007
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.
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.
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.
Subscribe to:
Posts (Atom)