The ‘Links to Non-Silverlight’ Folder

One of my arguably neurotic mental background tasks for weeks (months, probably) kept provoking the question, ‘How the hell will my Silverlight BiggestBox project package nicely for CodePlex.com?’ To place this question in some kind of relevance:

• The concept of the ‘Biggest Box’ is my way to approach the interactive User Interface, which starts in CSS and then moves into XAML.

• My Visual Studio document image has Solution Files (*.sln) sharing the same folder. This arrangement allows multiple Solutions to load the same Project. This is hostile to Team Foundation Server and the default Visual Studio option covered in “How to: Create Directories for Solutions.” (More on this below…)

• Since Silverlight compiles for a different runtime than .NET for Windows many of my .NET libraries cannot compile. However, there are many, many, many types that do compile. To avoid copying these files into Silverlight projects, my preference is to make links to these files. These links lead to Visual Studio projects. These Visual Studio projects can be rolled up into a logical Visual Studio Folder. Thinking about this leads me to call this logical folder the ‘Links to Non-Silverlight’ folder.How the hell will my Silverlight BiggestBox project package nicely for CodePlex.com? How will my ‘Links to Non-Silverlight’ folder package ‘nicely’ for CodePlex.com? These look like an answer:

• Visual Studio Project files use relative paths by design.

• NAnt is already in my regimen to automate packaging nicely.

• The number of non-Silverlight projects should not greatly exceed the four projects in my BiggestBox project (because non-Silverlight project growth should be for data access and “business” logic).### The Four Non-Silverlight Projects in My BiggestBox Project

  Songhay	My most primitive .NET library of reusable, static utilities. (The term `Utility` is meant to get away from the word `Helper`, which refers to HTML Helpers for ASP.NET MVC as far I’m concerned.)
  `Songhay.Composition`	Definitions for MEF Composition and something I’m calling ‘Composition Messaging.’
  `Songhay.Data.Linq.Opml`	Yes, I wrote my own OPML library under what some would call the “crazy” assumption that the OPML `outline` is a great data format for menu item meta data. This use of OPML is dramatized most effectively in my [UriTree](http://uritree.codeplex.com/) project. This is where any accusations of “over-engineering” directed toward me are not easy to dismiss out of hand.
  `SonghayCore`	My most primitive .NET library of reusable, static utilities for 3.5, 4.0 and beyond. I’m not moving my older `Songhay` stuff out of .NET 2.0 because of my historical concerns for [Mono](http://kintespace.com/rasxlog/?p=856) among other things.

  ### Why Multiple Solutions Sharing the Same Project?

  It became clear to me that many professional developer teams prefer to use source code over binaries in their version control systems. Indulging in this preference with my code, leads to multiple solutions sharing the same project.

  What’s deeper into my personal preference is finding out that, say, approaching an XML utility library from ASP.NET is different from using it in WPF. Ensuring that such a library works in both contexts makes the library ‘stronger’ or more generic, more versatile…

  rasx()