Building Silverlight Toolkit (again)

Paths I find most useful - especially when compiling SL Toolkit 4.0 from source (on an x64 machine). For whatever collection of reasons (IDE resolving assemblies, poor source-code structure - whatever) I usually end up wasting x hours of my life (usually on the weekend) trying to resolve these things. The Design solutions seem to be the worst offenders. 

The saddest comment I saw posted on the message boards (from a moderator no-less) was along the lines of - "Well, just don't build those projects." 


The sound you just heard was me throwing up, just a little bit...

Anyway - some of magical GAC paths....


(Useful for the little things - like System.Windows and System.Windows.Controls)
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\

(For the Blendability aspects - notice the 10.0 - instead of the 9.0; which is generally how the IDE(?) resolves it)
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\

(For the all the references that look to C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Libraries)
C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\

I love what SL has done to the CLR - I really do! In general, the IDE is a pleasure to work with but that said....

• My best advice is stop using the GAC! Use the shared binary folder (only if source is unavailable or overly prohibitive) for the shared dependencies consistently and across the board.
• Where's the automated batch build? If Code-Plex = MS <3 OS  at least follow some basic principals... 
• The few tests that there are suffer the same path dependency problems as the rest of the project. (No automated build - or automated tests?) 
• Developers are your audience - and we are relentless when we don't have a sense of assurance with the project we are working with. It needs to be clear, well-organized and predictable. I've personally abandoned Open Source projects for less than this.
• Source-tree restructuring - make-over is well overdue. What a bloody-mess! (Take a look at the majority of projects at github if you want to see how its done.)
• All this being said - I want SL to succeed; but MS needs to want their developer base to succeed. We're paying attention...are you?

Every minute (wasted) compiling/resolving references is a minute NOT spent writing those oodles of apps required to catch up to Apple, oh - no wait - it Android now.
 
Assimilated the new Android SDK yesterday -> was out for about 15 minutes as the emulator changed paths and Eclipse required an update. Just saying...