ISerializable - Roy Osherove's Blog

Cool! I had heard it was possible, but never seen how, so thanks.
Now, one question, do you know what happens if someone without
the enterprise version of VS.NET tries to open up this this solution?

Paul: Glad I could help out. No idea what happens when you open it with a non-ent. version though. :(
I'd love to know if you ever find out though.

<p>
This just sort of popped up onto my radar after reading Roy's post on creating group projects under a single solution. Roy states the advantages of this from a TDD perspective as follows: "For example, usually I'll have a pair of projects for each Application tier, one for unit tests and another for the tier implementation (“Dal“,“Dal.Tests“). Using such a folder scheme as mentioned above I'd have a folder under my solution called “Dal” under which these two projects will reside."
<p></p>
While I agree that the group project idea is great, the one thing that bothers me is the example. More specifically, the namespaces there. Anyone see it ? It's right there, "Dal", and "Dal.Tests". No takers ?
<p></p>
The problem with this arrangement is that all classes in Dal.Tests will be a part of the namespace Dal as well. What this means is that any internal classes to Dal, which you obviously didn't want anyone to know about outside the Dal project, are suddenly accessible in Dal.Tests !
<p></p>
Now, if you are the only developer working on both Dal and Dal.Tests, you'd probably remember not to make any use of InternalDalClass or any other internal classes. But, in many cases you're not the only developer. And in almost all cases, you're not going to be the only one maintaining the code over time. So, some other developer when writing a test class in Dal.Tests would see just another class he could use to test the functionality of Dal.
<p></p>
This is OK if you intend on doing white box testing. However, I think that it is generally agreed that black box testing be done outside the project (Dal) while white box testing be done within. ( If it's not generally agreed, well, sorry, but I've seen it done a lot, and the logic behind it makes more sense than all the alternative approaches I've seen. )
<p></p>
So, for black box testing, instead of "Dal.Tests", just call it "DalTests" and voila, a separate namespace where the internal classes of Dal are not accessible.
<p>

> do you know what happens if someone without
the enterprise version of VS.NET tries to open up this this solution?

I havn't checked myself, but I'm quite sure that it the solution would load, but that the project wouldn't load and instead would appear grayed out. VS.NET is an extensible platform where you can add new project types. For instance, ActiveState has something called Visual XSLT which makes it possible to create a new type of XSLT project in VS.NET. But if somebody without this product tries to open the solution, the project will be unavailable. The Enterprise Template is just another project type. Try to open a solution file in a text editor. You will see some GUID's that most likely identify the project types and the add-ins used to load these projects.

The thing I am trying to figure out is how you can, as an "architect" make a template solution ot be consumed by your development groups. Creating the solution is straightforward, what I am missing is how the developer can consume it, without the possibility of modifying it.

Thanks,
Brian

BTW - already been here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxwlkwalkthroughcreatingnewenterprisetemplate.asp

Wayne Allen's Blog