More Visual Studio shenanigans

I just received an email with some light detail about Visual Studio 2012 update 3 RC.  After having a look at the lean list of fixes included and the news that MS is prepping for VS2013... well I was pretty disapointed.

Suffice to say that effectivly I have not been able to use VS2012 for much of anything.  Its either been feature incomplete or buggy as shit to the point of unusability.  So apart from not progressing a couple of projects... I will essentially have to skip a whole version before (hopefully..) I can make some progress.  Talk about stealing momentum.

While I understand that VS is an "everything and the kitchen sink" type toolbox and getting it to all work is a herculean task... it seems like this version has just sucked constantly.  Its been such a political release with MS trying to strong arm their agenda for Win8 down my throat that I am just disgusted by the whole experience. 

The sad thing is that Win8 would have been picked up and used quite happily as part of the natural cycle and no one would have mentioned it.  We would have migrated everything in our own time and at a comfortable pace. But the whole "forced adoption" policy just broke too many things all at once and really did not leave me with a path forward.  And that left me holding the bag and trying to explain to a lot of clients why I could not deliver what seemed to be a simple update for a new Microsoft Platform.   You just cannot do that and not expect to cop some flack for it.

Diversification is the only way to manage risk across a broad portfolio.  So now, I have to diversify and spread my position away from Microsoft.  I have to maintain a number of possible solutions on a range of platforms and middle ware rather than relying on MS to be both platform and middleware provider.  The trust is gone.  I have spent more time reviewing tools sets and API's from other platforms over the past year than any time previously.  I have had to develop on a dozen different middle ware packages and push more projects into the cloud that otherwise would have been on the MS desktop.  All because they moved my cheese and pissed all over it.

And for what?  Has the MS position in the market place been strengthened?  Hardly.  I still can't find a supplier in the city who cares about selling surface tablets. There are now just as many Mac products amoung my clients as there are PC.  Chrome books and Android tabs are breeding and market place apps are spawning like crazy salmon.  The monopoly is gone; panicing is just making it worse.

Visual Studio Update fixed flickering bug

Today I happened to start Visual Studio 2012 for an indirect reason and it told me there was an update for NuGet availible.  I let the update install... and then restarted and....   the horrible flickering and endless instability were gone.  

This behaviour has been paralysing my use of Visual Stuido for months.  I guess I can finally get back to the job I have had on hold... once I finish all the others that have filled the vacumme. 

Whoot!

(So, in hind sight... I guess its been the best part of 18 months since I have been able to make meaningful progress on that job due to all the f@#% ups with Visual Studio, Win7/8 and the features that were missing and finally showed up in service pack 1.  While my disgust knows no end... I have been using a bunch of other developement tools recently and know just how polished VS really is... despite some of its crippling flaws)  What a frustrating life we get to lead....

More Custom Build Rule Hacking

I have tried to live with the broken build rule but its making a mess of my builds. I just don't have time to waste nursing each build by hand... AHHHHHHHHHHHH!

So the only thing for it is to fix the freakin build rule.

The symptoms are:

1) The  "Output Directory" property is not being correctly calculated by the build macro (?)  and passed to the command line string which is passed to the HelpNDoc compiler.  I can see this in the output.log.
The big problem is that within the property pages, the command line string seems to be being correctly calculated and looks good.  WTF?

My hypothesis is that the evil lies within the .target file as this seems to manage how the information from the property pages is passed to the build system.

Fiddling with the .XML file.

As a first step I am going to "experiment" with the .xml file just to see what happens.

It looks like some of the categories are not being clearly defined, so I will add a couple of them to see what happens and see how the change-reload-test cycle works.

Unload and Re-load project do not seem to reload the changes?
Unloading and Re-Loading the Solution does not seem to reload the changes?

Time for some serious breaking.

I removed the .xml, .targets, .props files from the project directory just to try to force a failure. Thankfully I got an error.

E:\_dev\PointLightLab4\src\HelpPrj\HelpPrj.vcxproj : error  : The imported project "E:\_dev\PointLightLab4\src\HelpPrj\HelpNDocRule.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.  E:\_dev\PointLightLab4\src\HelpPrj\HelpPrj.vcxproj

So it looks like the .props file is the first to be loaded and parsed. Interesting. Lets add it back and try to reload the project.

Still failing with the same Error?  WTF?  Is it just a spurious error?  Its from an statement in the .vcxproj file... so perhaps I should have a look. 

Found it.  The project seemed to be using the backup copy of the build rule I had in another directory.  Weird that the path in the error was wrong.  It should have been "E:\_dev\PointLightLab4\src\HelpPrj\BuildRule\HelpNDocRule.props" as that as the path in the .vcxproj file. Yet another MS bug?

Ok, we are passed that error. Now the missing .targets file is being correctly detected.

Loading E:\_dev\PointLightLab4\src\HelpPrj\HelpPrj.vcxproj ...
E:\_dev\PointLightLab4\src\HelpPrj\HelpPrj.vcxproj : error  : The imported project "E:\_dev\PointLightLab4\src\HelpPrj\HelpNDocRule.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.  E:\_dev\PointLightLab4\src\HelpPrj\HelpPrj.vcxproj

Replace the .targets file and the project "Reloads" without errors.  I guess the .xml file only gets parsed when I try to open the Property Pages. So its not been missed yet.  Lets test that theory.

Nope.  The property pages work fine without the .xml file being present.  I guess its completely useless?  The properties are certainly being defined without it. 

So I think my hacking needs to focus on the .props and .targets files.

There is a mess of properties for the HelpNDoc build rule defined in the vcxproj file as well I notice. Which makes sense. 

Added a couple of lines to the .vcxproj file.
*.chm,*.pdf, *.html
    *.chm,*.pdf, *.html

As the extensions where only defined for the debug builds for some reason.

Interestingly, when I make changes to the .vcxproj file and have the property pages open in VS, it detects that the file has changed and offers the option to reload it.  Nice! Although the changes I made are not showing up... WTF?

I still cannot figure out where the definitions for the property pages are comming from.  The .xml file is not being loaded at all, so it has to be at some point in the load chain.  Time to backtrack.

It's not in the .sln file.
It's not in the .vcxproj.user file.  (Although that needs some additions for new platform targets I have added)
It's not in old user files.

Somewhere its being cached. Bastard!

Ok, remove everything, unload the solution, close Visual Studio... reopen VS, reload the solution and... TAfuckingDA the custom build stuff has disapeared.  Finally.

Now can I add the .xml file back in? Replace the .xml file in the project directory.

Unloading and Reloading the project does not pick up the settings again. Ok, cycle the whole solution... no joy.  Cycle the whole VS.... and they are back.  OK, so essentially, fucking with the .xml file requires a complete cycle of Visual Studio to see the changes.

Making Progress.

Now to get all the categories defined and named the way I like...

Ok, all the categories are correctly defined in the category section and I have removed the spaces from the names simply from habit.  They now have nice display names too.

So the 's seem pretty straight forward. They are defined in the .xml file, and their "name" attribute is referenced in the .props file with what look like default values. These default values are then over-ridden by any values in the .vcxproj file (in th tag) and additionally over-ridden for each build target /platform (in a tag), again simply by referencing the property names defined in the .xml file. 

First order of business is to explicity set the values in the in the .vcxproj file for all the build targets. 

Try building again...

I'm getting an error about the .props file cannot be imported again. with a line and col reference in from the .vcxproj file.  Ok, looks like I have accidentally imported the file again in the ImportGroups that I copied earlier... wonder why it was there in the first place? Anyway, fixed now.

Now looking at the logs in the intermediate directory... the command line is correct.
And in the output directory?...... WhoooT!  We have output files correctly targeted!

Now, the /silent flag is not acting correctly. Tweak the .vcxproj file and we have success.

Now moving on to improving the custom build rule for HelpNDoc....

Found this reference for the MSBuild Syntax.
http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx

And an overview of using and createing build files
http://msdn.microsoft.com/en-us/library/dd393574.aspx

Would have been nice to know where these were a while back...

It's only after you have figured out the answers, that you really understand how to ask the question.  Damit.

After some reading...here is the final resource.

As usual with forums, your milage will vary considerably....
http://social.msdn.microsoft.com/Forums/en-US/msbuild/threads

Custom Build Rules in Visual Studio 2010

Yet another upgrade quirk.  The editor for Custom Build Rules in VS2008 has evaporated.   This is due to the changes in MSBuild... I appreciate that...

I had a coupld of custom build rules in my project and have recently upgraded it all from VS2008 to VS2010 and expected it to "Just work".

This is not good.  Thankfully the folk at CodeSynthesis had already sorted out the build rule for XSD  http://wiki.codesynthesis.com/Using_XSD_with_Microsoft_Visual_Studio  and supplied a custom build rule that sorted that out.

Now I just need my build rule for HelpNDoc3 and I am back in business.
My problem is that the Upgrade Wizard, while its obviously done a fair job has either revealed some bugs in my old rule ( and faithfully upgraded those bugs) or its just done a shit job... either way, there are some issues that need fixing and no one else I can push the work onto.

So the current process seems to be:

A) Go use the editor in VS2008 to generate the .rule file and then use the migration wizard to transform the rule into the .target, .props and .xml files for VS2010.  Big round trip... lots of moving parts.... but a possibility.

B) Hand edit (hack blindly at..) the three files and try to figure out what you are up to by looking at the malnourished references and examples included with VS2010. Big round trip to test, lots of unknowns,  ( there will be PAIN)

C) Hope like hell someone else has already done the work and documented it.

http://blogs.msdn.com/b/vcblog/archive/2010/04/21/quick-help-on-vs2010-custom-build-rule.aspx

Not much to go on but its something.

Hack'n time....

The .XML file

This file defines the property editor interface for use in the solution explorer.  After spreading it out in my favorite xml editor and doing some reading, it seems fairly straight forward. 

This file uses the XAML schema for WinFX.  http://msdn.microsoft.com/en-us/library/ms752059.aspx.  I dont think VS is using the info in the file as real xaml; its simply structured data that happens to be using the schema for parsing purposes.

If we follow the namespace breadcrumbs I find: http://msdn.microsoft.com/en-us/library/microsoft.build.framework.xamltypes.aspx which seems more meaningful as to the content than UI xaml which this file clearly does not contain.    This gives me enough clues to take some guesses at the structure of the data in this file but no fucking idea about the logical effect of adding or removing elements from this file. Where does that info exist I wonder?

Here are some clues:
http://blogs.msdn.com/b/vsproject/archive/2009/06/10/platform-extensibility-part-1.aspx
http://blogs.msdn.com/b/vsproject/archive/2009/06/18/platform-extensibility-part-2.aspx

The .props file

This file seems to contain default values for some of the properties defined in the .xml file above.  (Why have them in a seperate file?)

There are some clues on this at http://blogs.msdn.com/b/vsproject/archive/2009/06/23/inherited-properties-and-property-sheets.aspx.  

and here

http://blogs.msdn.com/b/visualstudio/archive/2010/05/14/a-guide-to-vcxproj-and-props-file-structure.aspx

The .targets file

This file contains a whole lot of shit.  Mostly it defines the output for the build file.  Logically this defines how the property values from the editor are mapped into the actual build script.  Looks hideous and nasty and will be damn hard to debug simply due to the length of the round trip and difficulty of getting useful/meaningful error messages from the build system.

The .VCXPROJ file

This file contains (along with everything else) the actual values for the properties as applied to the file item.  These are the values at the bottom of the property inheritance chain.  (See the link above under the .props file heading for more info on property sheet evaluation orders)


Looks like you can do some fairly tricky stunts in the property pages via inline function calls:
http://blogs.msdn.com/b/visualstudio/archive/2010/04/02/msbuild-property-functions.aspx
http://msdn.microsoft.com/en-us/library/dd633440.aspx

I have no use for these at the moment.