Core -> Domain + Framework

Jul 6, 2010 at 8:05 PM
Edited Jul 6, 2010 at 8:07 PM

Hi all,

In the documentation explaining how the projects are organized you have this:

Core -> Domain + Framework
We split out domain entities into the Domain namespace, and anything that was generic, core, functionality into the Framework namespace. The idea being that Framework could be reused across projects, however Domain was, well, domain specific.

-----------

But the Framework project references the Domain project as there are several interfaces defined in Domain that are used in Framework (e.g., IComponentRegistrar, ISpecification). If the goal is to have Framework be used across projects then there shouldn't be this dependency, right?

I think the fix is to just move some of these interfaces to the Framework project instead of in the Domain project and remove the Domain project reference in Framework. project.

Regards
Dan

Developer
Jul 6, 2010 at 8:36 PM
Yes, you're completely right. I keep meaning to fix that but not getting round to it. In the recent projects I've worked on based on WCHM it's one of the first things that gets corrected!

Cheers
Jon

On 6 July 2010 20:06, djs <notifications@codeplex.com> wrote:

From: djs

Hi all, In the documentation explaining how the projects are organized you have this: Core -> Domain + Framework We split out domain entities into the Domain namespace, and anything that was generic, core, functionality into the Framework namespace. The idea being that Framework could be reused across projects, however Domain was, well, domain specific. ----------- But the Framework project references the Domain project as there are several interfaces defined in Domain that are used in Framework (e.g., IComponentRegistrar, ISpecification). If the goal is to have Framework be used across projects then there shouldn't be this dependency, right? I think the fix is to just move some of these interfaces to the Framework project instead of in the Domain project and remove the Domain project reference in Framework. project. Regards Dan

Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jul 6, 2010 at 11:55 PM

OK, I'm glad to know that I'm not completely clueless. I've moved the various interfaces to the Framework project and changed the namespaces and everything compiles, so I was going to send you a pull request, but I can't get mspec to run properly. I keep getting an error from the FullBuild and the RunSpec scripts. When I try to run MSpec manually I get this exception:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Machine.Specifications, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

As far as I can tell all of the dlls in ReferencedAssemblies\Machine.Specifications are up to date and at version 0.3. Any ideas?

Regards
Dan

Jul 7, 2010 at 2:43 PM

I had this happen recently. Do you use ReSharper to run your unit tests? If so, check your ReSharper mspec plugin folder's mspec size. It will be 54KB, and your mpsec in ReferencedAssemblies is 60KB. That's a guess, of course.

I had a problem where my plugin and project refferenced assembly differed on size alone -- the versions were exactly the same.

HIH

Kurt

Jul 7, 2010 at 11:03 PM

Hi Kurt,

I did see your previous post on the Machine.Specifications.dll and how a ver 0.3 file can have two different sizes. I tried different combinations and nothing worked.

No, I don't use ReSharper, I was just running either RunSpecs.cmd or FullBuild.cmd from the command line. Perhaps that is where problem is, your resharper plug in folder has the correct dlls but the files in WhoCanHelpMe\ReferencesAssemblies\Machine.Specifications are out of whack.

I did take a closer look at the mspec files with Reflector and found the Machine.Specifications.ConsoleRunner.exe to be compiled against ver 0.2 of the dlls, but the other dlls all expected ver 0.3. Or maybe some were expecting the other ver 0.3 files. Anyways, I downloaded a fresh copy of mspec from github, compiled it for .Net 4.0-Release, copied over the new dlls, and ritualistically slaughtered a chicken just to be sure. Yea, it worked!

Thanks
Dan