Update to Visual Studio 2012

Issues

No deployment projects in VS 2012

Both the PLL Player and Editor pack and the PLL Model Pack projects are no longer supported.  The wix project that I was working on is also not supported.  The suggested solution is to use


Visual Studio Macros unsupported

All the macros that I have hand built over the years are now dead.  Probably not a bad thing, and the replacement is nice (add-in's) but it is still a pile of work to migrate anything that I still need/want.

wxGUI for PLLEditor compiled... whoot

I have finally sucked up enough pain to continue converting the GUI over to wxWidgets.  This has been an on-going distraction for a couple of years.  Today I got it to build!

This opens the door for cross platform and disentangling myself from WinForms.  (They were much better than MFC but the current state of C++/CLI makes WinForms a really bad future bet.  But that Rant is for another time and place.

Suffice to say that I have a scratch GUI building in Visual C++ over wxWidgets 2.9.3 using wxFormBuilder as the GUI editor. 

I finally feel like I can make progress without digging myself into a deeper hole (WinForms...) now I'm digging upward. 

It will take a huge amount of time and energy to convert all the winforms code back to clean C++ but having decided on a GUI toolkit... its now possible.  (Sorry QT it was never meant to be)

Progress...

Bug Fix - TODO commands in Experiment Editor

I have removed a bunch of TODO commands in the experiment editor.

Utilitites - Display Modes Enumerator
Utilities - Keyboard Scan Code Utility

Experiment - Package Experiment
Experiment - Validat All Files.

These should be re-added at some point as they are still useful features but not just hang in limbo taking up space while they are unfinished.

Bug Fix - About Dialog crash

Fixed a weird bug with the About Dialog in the Experiment Editor.  It was crashing because it could not find an Icon resource that was clearly there.  Don't care. Icon removed. Bug fixed.

Bug - Audio Editor - Does not clear the editor interface when file fails to load

When a file fails to load for any reason the Audio Editor does not clear any existing data correctly.

Bug - Audio Editor - Tries to save changes when no change

Audio editor tries to save changes to a file that has not been changed.

Bug Fix - Editor - Load XML files not reporting errors correctly

Fixed a bug that effected all the PLL file types where the XML parser was not correctly reporting errors with the document back to the User.

This specifically effected bad DTD paths embedded in script, model, audiotrac, experiment and config files.

Update the setup and deployment projects to use the Wix toolset

Download Wix 3.6 beta.

Install is funky but appears to work.  

New options in the Add New Project dialog.... so the installer has integrated with VS2010 correctly.  Nice!

Option to target different .NET framworks... intersting but I am upgrading everything to .NET 4 at the moment; so 4 it is.

Created the project file in a correctly named and placed directory.... Nice!  Although it has created an output directory in that directory.... not nice. 

Now to troll through the properties pages and get it doing things the way I want....

Turn up the warning levels

Put a mega macro in for the output path.  $(SolutionDir)bin\$(ProjectName)_$(Configuration)_$(Platform)\

Lets see if it can choak that down.

Ok, made a little bit of a mess in the build targets.  Since one of my platforms is Win32 and the other is x64... naturally it created a new one called x86 and made a tangle of the other two.  So with a little editing and deleting in the wixproj file, its all better.

Just found that I have a whole slew of build targets in some projects that are no longer needed.  More deleting.
Found a couple that cannot be deleted...???? Unload reload cycle first.  Drop all the xml files from Notepad++ that I have been hacking on....

A little more hacking in Notepad++ to remove all references to the unwanted targets and tada!  Reload project... no errors.  Check in the Build Configuration Editor... no more crap targets.   Shiny!

Now I can get back to upgrading the Setup projects.

Unresolved typeref token

I have had a pair of link warnings hanging around for a while:

warning LNK4248: unresolved typeref token (0100001A) for 'xercesc_3_1.XMLGrammarPool'; image may not run

and

 warning LNK4248: unresolved typeref token (0100001E) for 'SNDFILE_tag'; image may not run

Since they are not terminal... they got less attention.
I have tracked down some information on the subject. 

http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0730e965-7299-44ca-8a95-59e2eb23d153

There are two good solutions posed in the forum.

1) Include a supression command on the linker command line

Under Configuration Properties -> Linker -> Command Line -> Additional options, add "/ignore:4248" (without the quotes).

2) Include an empty definition for the incomplete types.

I.e

struct WeirdTypeNameHere {};


I've chosen this option becasue the types are defined in third party libraries ( xerces and libsndfile ) and I don't really want to hide the problem on the linker command line.  Its just too easy to get lost in all the property page mess that I have spent the past week untangling.

Rebuild the Build System in PLL

Spent most of the day cleaning up and straightening out the build configurations for the PLL solution.  The amount of crud that had built up over the years was slightly bothering. 

Anyway, all the paths are now using VS macros correctly to generate output paths and names, the include and lib directories are all using environment vars where approrpiate.  All the weird target names that seemed like good ideas have been standardised. 

I even gave the project directory a house clean and got the folder locations standardised.  Got to delete a whole bunch of cruft and get the clean setup checked into SVN. 

Untangled the Setup projects dependencies on old version of .NET and updated it to the current generation.  Also relinked with some files that had moved around.  More testing to do on this later.

Had a platform inconsistency with libsndfile-1.dll where I had installed and was using the x64 bit version while compiling for 32bit platforms. It was only the setup project that complained... fixed that.

Changed the name of the HelpProj to use a consistent naming scheme with the output file.  Untangled a mess with HelpNDoc's command line options acting weird.  Although I think this has as much to do with my custom build rule as it does with inconsistencies in the handling of some flags in HelpNDoc.  More work needed there.

Got rid of a mass of old directories in the bin\ directory that were old output targets.  They had a weird naming scheme that made sense at the time but has had its day. Just need to update all that in SVN and put it all on the exclude list. 

So after nearly a week, the project is building without errors. Has mostly been housecleaned and is ready to make some progress on.  The bug list needs some love.

Getting PLL to build on my new machine - Help N Doc Update Step

Just need to get my help project to compile... but naturally my license has run out for the help compiler.  Online purchase.... print invoice, lodge expense claim  20 min later.... Download new version. Install... etc etc etc.

Got to add Help n doc to the path.  Restart visual studio to pick up the change.

Now I just have to re-create the custom build rule for the help project. Looks like it converted this time.... its working... its working.....

Naturally it threw an error while trying to generate the pdf help file.... Seriously... can I catch a break?  Can one thing just fucking work?

Delete the existing file?  Nope.
Change the target name?  Nope.

Go and try one of the other help projects in a different project.... even more errors with this.

Unhandled exceptions
CHM Template didnt generate any HHP project file... choaking.
An error occured while starting the PDF generator. Make sure the file is not in use.???
Kindle generator could not be found (Since I don't have one... I can probably explain this error)
.....

Basically the only bit that worked with my new smelling help compiler is the epub version.... not fucking impressed.

Log a bug report with the company and see what happens.

Getting PLL to build on my new machine - libsndfile update

The LibSndFile Update 

I use libsndfile for one small routine in the editor to figure out the length in time of a sound file. 

So, download the current package, looks simple enough.  Plug it in, environment variable, add include and lib directories to the project, run a build... and get a set of link errors.

It turns out that libsndfile is all c (with a nice c++ wrapper now) so I do a little coding and use the c++ wrapper class.Nice.  Fiddle around with the includes and get the files in the project sorted out. (Previously I had libsndfile headers included directly in the project for some reason.

Anyway, get it all neat and tidy, run the build again... link errors. Easy enough. Verify the headers are being found on the include path, verify the link path ( uses the same environment variable)

Once I am happy that its not a weird typo or something in the link path, and I stuff around with a #pragma comment(lib,"libsndfile-1.lib") just to check that the file is being found.... I get back to the undefined sysmbol.

The symbols seem to be in the libsndfile-1.def file and in the .lib file.  Much as the name mangling makes sense, at least it looks like its probably nearly there.

Anyway, guessing its due to the dll being compiled with a different compiler, the usual solution is to try to build it with my compiler, for my architecture etc. So  pull down the source gz and unpack it.  Then read the docs and find that due to the weakness in the MS C compiler, there is no way in hell I can compile a new copy.

Anyway, in the docs I find a reference to re-generating the .lib file from the .dll using the lib.exe tool.  New one on me.  Anyway, makes sense. All I need is to know the link points and the name mangling I guess and the linker does the rest.

The command line is:

lib /machine:i386 /def:libsndfile-1.def

But getting this command to run was incredibly frustrating. 

Open a command promp in the lib directory.  Try to run lib.exe.  Cant be found.  Find it and include it in the path.  (C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\lib.exe)

Once I get that done, it will not run due to mspdb100.dll is missing...

Run a search and find there are about 4 copies of that file in different architecture directories and one in the Common7 directory.  I guess common7.  Try a little copy past magic... no love. Undo the copy paste hack.
Google a bit.  Find references to using the VC command prompt... but its no longer included in the install.  I know there is usually a batch file to set the environment for any command line play... where the sausage is that? Looks like a winner in the directory with lib.exe  (vcvars32.bat) sounds nice. 

So with a little command line magic, I run that batchfile and then lib.exe and ... fail again. WTF? Still no mspdb100.dll ? More googling... find a comment in a forum on stackoverflow mentions a different batch file (vcvarsall.bat). Doesn't say anything useful about it... Play hunt the file, contains a bit of batchfile magic which picks between architectures to set up an environment... so looks like a possibility.  Run that... run lib.exe and tada.... lib.exe now works. .lib file is regenerated.

Build now works and link errors are banished.  Now if I simply undo a couple of steps.. they should re-appear and confirm my understanding.  <Undo steps to cause link errors> .... WTF? They are still not comming back.?????????  Now I'm really confused.

Have I fixed the environment? Did I fix the .lib file? Did fairies just stop messing with me?  What did I do to fix the freakin errors? 

Ok, totally clean the output and do a rebuild.... still no link errors.... turn the linker onto verbose just to see what it sees...

Talk about frustrating. I can cause all the usual errors by messing with the linker additional library paths... but I cannot cause the undefined symbol errors again.  Why not?  I want my errors!  (If only to prove that I didn't waste hours sorting it out because it a freakin typo or something. 

Ok, working backward into the vcvarsall.bat and from there into the vcvars32.bat... there are a whole bunch of environment variables and paths being set that I probably cannot unset easily.

The main vars are:

VS100COMNTOOLS (Permanent Change)
LIBPATH  (Temp Change)
LIB (Temp Change)
PATH  (Permanent Change)
INCLUDE (Temp Change)

I would not expect enough to be different in the path and the VS100COMNTOOLS vars to "fix" the link errors but it seems the only possibility at the moment.

After some buggering around... there comes a point of diminishing returns to re-create an error that I did not want in the first place. 

Need  a copy of WinMerge to check the two lib files and try to determine if they are being regenerated or not.

Hmmm.. I'm out of time and need to move on to other things.... this is really frustrating.

Getting PLL to build on my new machine - DirectX Update Step

DirectX Update

I have been avoiding updating DirectX for a couple of years as I was using XP for the development machine (long story)

So now DirectX has been rolled into the Windows SDK... Eh!  I would probably have needed that anyway.  Time for a mega download.   Waiting waiting waiting..

Naturally its broken.  Fails too find files at the Microsoft Site...

So I need to roll back to the previous SDK and .Net Framework 3.5 SP1  installer.... will this one work?

Its been sitting at the "Preparing" screen for a couple of minutes now.

 

Update.... 2 days later... this saga is still ongoing.  After all sorts of broken downloads and web scrounging. I think I have the Windows SDK downloaded.  Really, I'm not sure its complete but have just stopped caring.

I tried compiling and found that the headers in the SDK have changed and lost some key DirectX 9 headers I was using..... Blah.  AAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHH!  I feel like I have just wasted the past two days.

So in a last ditch attempt to get something moving, I am trying to download the last DirectX 9 SDK (June 2010)  which, fingers crossed I might still be able to use.  This will hopefully give me a smoother path forward.

I really don't want to re-write all my rendering code and graphics system (Again).  It's just a little too depressing to face right now.

It's enough to make me learn OpenGL.... nearly.  (Nothing wrong with OpenGL... I just have never had enough pain to jump...)

I keep looking at SDL but the documentation is just tooo Lite.  I can foresee pain without answers.  OpenGL is about as unsupported as I feel like going.

I have had a look at QT and OGRE again but they are still doing their own stuff. 

If Nokia tanks then QT will be in a bad spot (quite likely picked up by someone else but its still uncertainty....) while OGRE has too much "hack" still in it for a project I can't aford to frollick around with.

It's also got a different architecture that would mean I needed to rebuild my work substantially.  I really don't want to do that.

I really, really don't want to do that.  I've essentially written the graphics system for this product 4 or 5 times already over the past half decade. You would think it would be totally done by now.

This makes OpenGL a reasonable and I feel... only.... candidate for swapping out the graphics system.  May need to look at QT again when I'm more awake.  Wonder how fast I can download the QT SDK?  Hmmm... 1.7G in just over 1 minute... what do you know... they are comming of another Akamai server... lol.  Different IP's.  They are both located somewhere in Sydney but one is one step further than the other after the last aarnet hoop. (The unusual box is in the QT trace so its not the culprit in the slow Microsoft download...weird)

Anyway, I'm out of time this week...

So after downloading the installer DXSDK_Jun10.exe for the June 2010 version of DirectX9 and installing it,  add the include and linker paths and compile and we are shiny!.  (Well except for the next lot of errors about libSndFile.

Getting PLL to build on my new machine - XSD Update Step

XSD Update

http://www.codesynthesis.com/products/xsd/

Get the latest, install, set an environment variable for the directory.  Do I need to plug in the binaries?
Restart Visual Studio to pick up the changed Environment Variable. Build.

Runtime version mismatch.... damit

Now it will not run the compiler......

Ok, got it to use the xsd.exe by putting it into the bin path correctly. But its failing with "The Handle is invalid"???? WTF? A File Handle? Is it open somewhere?

Tried picking apart the error by running the command line in a dos box.  It seems that Visual Studio is passing a bunch of flags to xsd.exe that have nothing to do with xsd.  Now Microsoft have their own XML compiler.... How do I turn that off?

So is it trying to treat it as an XML document or as XML Data?  Those seem to be the properties that are most likely. 

Ok, figured out how to set the custom build tool settings.  Right click on the file itself and go into the property pages. On the "General" set "Item Type" to Custom Build Tool.  Then its similar to the old custom build rules.

Now I find more info.... shit.
http://wiki.codesynthesis.com/Using_XSD_with_Microsoft_Visual_Studio

Ok, looking better.  Now I just need to figure out all the settings I used to have in my custom rule for xsd again... damit.

Ok. Plugged in the custom rule stuff.

There is now an enforced suffix on the generated parser skeleton files that was not there last time.  I can't figure out a way to turn it off.  So have to re-name all the files in TortoiseSVN.

Once thats all in place, the files are generating again, but they have different namespaces and type names, So I will need to check that there are no dependencies messed up.

Getting PLL to build on my new machine - Xerces Step

Xerces Update Step

Now I need the Xerces includes... yuck. Every time I update Xerces lots of shit breaks.   

Get the latest Xerces.... plug in the include directory into the project (will probably have to do this for all the projects now... damit) Try to build the tests... whoot! Passed the includes... now just need the libs for the linker.

Now just a matter of plugging away at all the hundreds of errors....

Remember to re-start Visual Studio if I change Environment Variables for the XERCES_DIR etc. Build.

Done.  Colour me impressed.

Doxygen Update

http://www.stack.nl/~dimitri/doxygen/

Wow still using FTP after all these years.... I feel so oldschool when I get back into C++ work. Every tool seems to have some "back in the day" cruft still hanging around.  Just don't tend to see much any more.

LibSndFile Update

http://www.mega-nerd.com/libsndfile/


Download 64bit installer, install into my libs directory and set an environment variable.  Easy. Plug it into the project settings, (it was still using an explict path for some reason...) Restart Visual Studio to pick up the changed environment variable. Build.


Done.

Getting PLL to build on my new machine - CppUnit Step

This is the second post in a series logging the steps I have to go through to get PLL to compile on my new machine. 

CppUnit  update Step

http://www.freedesktop.org/wiki/Software/cppunit

This is now hosted in a Git repo, so I need a Git client... TortoiseGit looks like the best player as usual... do I really want another shell integrated tool?  Can I just use it and uninstall it?  Why can't the maintainers of CPPUnit just have a package for download?

http://code.google.com/p/tortoisegit/downloads/list

Oh wait... now I need MsysGit too... oh and its homepage has moved too... what a total armpit!
More installation options that I don't care about.  All I want is the freakin CPPUnit so I can get my freakin project working.

http://msysgit.github.com/

Ok, set up.. lets rock... copy past url into git clone... doing stuff....

"Git did not exit cleanly".   Fatal: I don't handle protocol 'git clone git' 
Take a guess and remove the bits that look like duplication.... success.  Whoot! only 32456 steps to go.

Now just some tweaking to add it to the search path.  VS has changed the way it handles include paths... they are now part of each project property set...

Set the path to the CPPUnit Include directory... minor fiddle and its working... whoot.  (Not built yet... just finding the includes)

First lets play build CPPUnit...

Convert the VS2008 project, check for errors... cross fingers and build the solution. 

Something died.  cmd.exe exited with code 1.  in DLLPlugInTesterTest Project. ????

15 Errors
170 Warnings....

Should I even bother?

Ok the errors are a cascade caused by the first failure.

The warnings however are only of two types.
152 x Warning C4251  ... blah blah needs to have dll-interface to be used by clients of class... etc.
18 x  Warnings MSB8012 about output path missmatches.

Changed the librarian output target for the cppunit project to Debug\cppunit.lib rather than Debug\cppunitd.lib which cleared all the errors and allowed the projec to build correctly and copy the file to the libs directory correctly.

Whoo Hoo!

Now on to cppunit_dll project

Remove the "d" for debug from the linker output target name to get rid of the compiler warnings.
After some fiddling around and remove the \.\ from the Output Directory and the Intermediate Directory (Do I need to do this in all the projects?) I also removed what seemed to be a spurious post build step

"copy "$(TargetDir)$(TargetName).lib" ..\..\lib\$(TargetName).lib"

As there did not seem to be a .lib being built ( its a .dll project?) this step was failing and blocking.

But now when I build the solution again, there is another project looking for the cppunitd_dll.dll in the libs directory?  Are you kidding?

Ok, quicky rename...

Build the solution again...

More errors due to the ".\" in front of the output Directory and Intermediate directory in all the other projects, so I removed them all in one hit.

Still cannot find the cppunitd_dll.lib to copy it.  WTF is it being generated?

Found where the libs are being generated and its got another explicit name reference that needs to be changed (Linker > Advanced) Remove the "d".  There is also a ref to cppunitd.lib in the other includes that is pulling in the from the libs directory that needs to be changed.

Money project has embedded "d" and a reference to cppunitd.lib on the libs path that needs to be fixed.

Ditto for CppUnitTestMain. Remove the "d" on the cppunitd.lib on the libs path.
Ditto for CppUnitTestPlugIn  which has a reference to cppunitd_dll.lib - remove the "d" and remove it from the target output name
Ditto for DllPlugInTesterTest
Ditto HostApp has two references in the libs path that need fixing.
Ditto TestPlugInRunner has two references two.

Go through and systematically check all the lib paths and remove the "d"s.

Change the ClockerPlugin to user a post build step rather than trying to directly write the output file to the libs directory.

Later...

Got  sick of changing all the absolute names and set them to $(TargetPath) instead.

After changing all the names in all the property pages, there are still references to cppunitd_dll.x showing up. I have finally tracked them back to the DLLPlugInTesterTest.vcxproj file.

There is a custom build rule in this file that does not appear in the property pages correctly.
msdn.microsoft.com/en-us/library/ee862524.aspx


This is a reference to what the file is supposed to be for.  The question is why its holding this weird reference that will not die and why I cannot edit it using the normal property pages.

DOH!

The stupid file is included in the project.  Thats where the damn reference has origionated.

Now to get simple_plugin working....
 OK. It has a bad name in the post-build step.  Fixed.

HostApp and CppUnitTestApp both have DLL dependencies that include the "d" on the end. Fix them and they run fine.
TestPlugInRunner also has a referene that needs to be fixed.

Now everything builds correctly and the only failure is the simple_plugin.dll test which is illustrating a bunch of assert failures.

We are done! (A day later...)Now I just have to include the include and lib directories in the relevant PLL projects properties.

At some point I may go back and add the "d" to all the debug builds, but honestly, I would prefer to simply build the release version over the top and replace the files.

Now just for fun, lets build the release version....


Here is another fix for CppUnit on Visual Studio 2010
http://blogs.powersoft.ca/erict/archive/2012/02/21/cppunit-in-vs2010ndashwith-a-sample.aspx

Now to fix all the warnings.

LNK4099: PDB 'vc100.pdb' was not found with ....  Copy the file from the debug object directory to the lib directory.

Getting PLL to build on my new machine

This is the bit I really hate about waking up a project after a bit of a break.  Things have changed.  Over christmas I finally accepted that I needed to upgrade my computer ( the old one had struggled along for a while and been fixed and bandaged together... )

So everything changed. OS went from WinXP sp3 32bit Pro to Win7 64bit Pro.  Had to update to VS2010 and move everything into SVN repos for the move to the new Hard disks.  (The fact that I ended up keeping one of the old disks turned out to be a bit of a save.  But the other rotten disk, containing all my libraries and a rotting pile of code and disk rot... when to the scrap pile.

So, now I need to bring one of my big projects out of hibernation... which means updates for all the tools packages and dependencies.... AHHHH

The next couple of blog posts will document the process.  (Like anyone cares.)

2012 first bugs

It's that time of year again.  Honors projects. Time to dust of PLL and start mak'n and fix'n.

Todays bugs....

1) Path error on Windows 7. This is due to absolute path's in the model files pointing to the Windows XP Program files directory (C:\Program Files\... etc), while on Windows 7 the default installation location is (C:\Program Files(x86)\...etc)

2) Path handling error in the movie tool within the experiment editor. This is due to the path being passed on the command line and not being enclosed in quotes correctly. Thus if the path contains a space, the command fails (this may accidentally write files in the wrong location... must check this)

3) If the model editor fails when trying to load a file, it fails silently and leaves the editor in an inconsistent state. It should fail loud.

4) Player will not autostart in windows 7. Ouch.