View Full Version : ISPROJ Conversion

Christopher Painter
05-23-2007, 02:53 PM
Sorry for being too busy during the demo to mention this, but here goes......

I use VS integration with TFS.

I upgraded my IDE and SAB and tried to do a build. Naturally it broke because the targets file has changed.

I opened up the ISM and it converted the project for me. But it didn't make any changes to the ISPROJ file so my build is still broken.

I'll go do it by hand, but shouldn't this be automatically done?

05-23-2007, 04:13 PM
It would probably make sense to do so, but there are definitely some small hurdles to overcome, such as ensuring exactly the correct <Import Project=.../> element was modified. It's been like this, requiring manual reconfiguration, since IS11.5 and I'm not aware of much feedback on this yet. Are you likely to modify an ISPROJ file such that /msbuild:Project/msbuild:Import@Project could refer to an import we should leave alone, or does that sound safe?

Just to clarify the scenarios I think we can handle, I don't see how we could resolve the first build error you describe. Until you upgrade the project, the first step sounds equivalent to uninstalling the previous SAB, and then expecting some other arbitrary install to satisfy that loss. After upgrading the project, it's just the misaligned Import causing problems.

Christopher Painter
05-23-2007, 04:27 PM
I try to make as little changes to the ISPROJ as needed. It's pretty much stock except for a change to InstallShieldMergeModulePath.

Thinking about COM..... would it be possible for you to make the import generic. Maybe have a pattern that defaults to
$(MSBuildExtensionsPath)\Macrovision\Latest\Macrovision.InstallShield.targets unless you specifically say point to xxx.

Kinda like COM.... abcd.efgh instead of abcd.efgh.1

Eitherway, it doesn't make sense to point a proj file to a previous engine once the ISM has had it's schema converted.

PS- I'd also love to get the source binding to work. I use TFS and it won't bind the source... .gives an ugly error message.

05-24-2007, 10:26 AM
Hmm. On one hand I like the idea of that 'latest' entry, which would be really easy for you to set up yourself by copying (or renaming) the MSBuild subfolder yourself, and optionally editing the ISProj template <ISInstallDir>\Support\0409\msbuild.xml. However if you had done this, and then we implemented upgrade tweaks to the ISProj template, I don't know how we could detect and avoid overwriting your pattern. I don't want to build in knowledge of all previous "legitimate" targets file paths in the upgrader, which means the best thing we could do is copy the value in the current template into the upgrading ISProj...

Alternately we could theoretically ask at upgrade, but I'd hate to set precedent which would eventually make upgrading a project more painful than clicking Next Next Next on the release wizard. :)

Christopher Painter
05-24-2007, 10:39 AM
hmmm, I hear you. You know, I never ever make changes to the TFS proj file. It has lots of entries that you can override by creating a harness proj file and then define the target. Don't do that and you get the default, do it and you get your way.

My main complaint was when I upgrade to IS2008 I had to go check out dozens of isproj files and update them. If there was a way to never make changes to those files but instead do something like above, that would be really useful. Then you would own the format of that file and could safely upgrade it.

I don't know... I'm so tired right now anyways I'm probably not thinking straight. I've got about 100 C# projects to go through and refactor so thatI can wire them up into a production build. It's very tedious and I'm just exhausted....

05-24-2007, 11:07 AM
Well, if you're looking for a band-aid solution that will let you migrate ISPROJ files at your convenience, assuming you're migrating all your projects to IS2008, you could always copy the IS2008 MSBuild folder to the IS12 position...

I like to think of the targets file as the one InstallShield owns, and the ISPROJ file as the one the customer owns, but here is clearly a place where that breaks down a little. Also since I don't get to use MSBuild half as much as you, I haven't internalized the patterns you can really use. I wonder if moving forward we'd be better off doing the import using a custom MSBuild property, which we could assert ownership of and update, and if you wanted to override that you could just replace its use in the import element. It'd still be a chicken and egg for existing projects, but at least future updates could become simpler.