This project is read-only.

Assembly Breakdown

Dec 2, 2007 at 11:49 PM
As we begin the design and initial coding stage for the new framework, we need to come to a consensus on the structure of the assemblies. The main question here is whether to keep the existing structure (one assembly per major (QuickStart.*) namespace) or combine it into one assembly. One of the lessons learned from working on the prototype was that there is not much advantage to the multi-assembly structure and can lead to DLL hell.

Though I originally advocated the multi-assembly approach, I now believe that the one assembly approach may suit our purposes better. This is a result of many factors, including XNA itself (we don't have any need to support multiple rendering APIs), and it would be a different story in the native world. For instance, the renderer will now be more of a library called from client code than a separate system. As such, putting it in its own assembly is just asking for issues, not the least of which is circular dependencies. For me, one of the problems I face is taking my knowledge of the native/C++ world and trying to apply it here. This includes project structure. If I were writing a game in C++, I would have no doubt about writing a library for each component, but here in .NET things are different and I'm slowly realizing that.

Everyone let me know what your thoughts are on this issue. Going forward, we at least need the coordinators be in agreement on the decision.
Dec 3, 2007 at 4:53 AM
I separated all the tools (like common math functions) into a separate namespace, but it didn't really matter much either way. I'm fine with a single namespace.
Dec 3, 2007 at 5:16 AM
I'm not referring to namespaces, I'm referring to assemblies.
Dec 3, 2007 at 5:46 AM
Edited Dec 3, 2007 at 5:57 AM
Well then I definitely agree. The entire engine in a single project makes sense. I can't really list any specifics, but I've seen entire high-end engines in a single project. Project is the same as an assembly right? I guess I should mention I've seen engines that are in many projects as well. I guess we can have it whichever is easiest.
Dec 3, 2007 at 6:59 AM
Usually multiple projects mean multiple assemblies, but there are tools which can merge assemblies into a single assmebly, so you can have multiple projects and still only have one release assembly.

I do believe that we will need a assembly for each platform, as there will be specific code for each. The base functionallity and interfaces all belong to the Core/Common assembly (Btw, should we use Core or Common for the main assembly?)

The helpers might need another namespace or not, depends on the usage. Have a look at the Math class in the .net framework, it's placed in the System namespace and not in a System.Helpers (or similar) namespace. The .net framework has some good guidelines regarding designing frameworks, one is that a namespace shouldn't be created if only a few types fit within.
Dec 3, 2007 at 9:56 PM
I vote for one assembly. I also vote for Quickstart.Core over Quickstart.Common, as it takes less time to type :)
Dec 3, 2007 at 11:59 PM
Well why even use core, why not just "QuickStart"?

Same as using.System;
Dec 4, 2007 at 12:59 AM
Interestingly, much of the System namespace isn't even in System.dll... it's in mscorlib.dll :)

Anymore, I agree with the single QuickStart.dll assembly, and having separate namespaces. Basically, just like the XNA framework does it.
Dec 4, 2007 at 9:11 AM

LordIkon wrote:
Well why even use core, why not just "QuickStart"?

Same as using.System;

I will change the names to reflect this.