StrataFrame Forum

Business Object Mapper - Populating Projects

http://forum.strataframe.net/Topic16181.aspx

By Randy Ayers - 5/6/2008

Is there a way to mark specific projects to be skipped when the Business Object Mapper is populating the projects within my solution?

I have many projects that will never have business objects.  This adds quite a bit of time when the Business Object Mapper is launched from within Visual Studio.

By Bill Cunnien - 5/6/2008

mark specific projects to be skipped

As far as I know the BOM works within a solution...it walks all projects in a solution to find potential BOs.  I suppose you could break out your business object project into a separate solution.  I have got nine projects in my current SF solution.  It is already a bit slow waiting for the list to populate.  I will be adding more in the near future.  Perhaps, SF could give us the option of specifying a project for the BOM in a given solution.  I would expect that to be a rather easy update.

Bill

By Edhy Rijo - 5/6/2008

Bill Cunnien (05/06/2008)
Perhaps, SF could give us the option of specifying a project for the BOM in a given solution. Bill

A property in the BO "IncludeInBOM" which we can make it True/False in the designer may do the trick.

By Bill Cunnien - 5/6/2008

That approach may still cause the BOM to walk the projects in order to find BOs with that flag set.  It may be better to have a setting in the BOM that allows the user to point the BOM to the BO project(s).
By Trent L. Taylor - 5/6/2008

Is there a way to mark specific projects to be skipped when the Business Object Mapper is populating the projects within my solution?

At present, no.  It depends on what you are doing with your solutions.  We generally break our solutions apart when they get to the 8 project level or so as many other things tend to slow down (just .NET IDE in general).  I would be curious how many projects you have in your solution because we have some extremely massive solutions with BOs strewn through multiple projects and the BOM comes up in just a few seconds.  Unless you have just some insane number of projects, the loading should be farily consistent in speed when coming up just due to the nature of how we enumerate the projects and class types through the DTE.

Having an option may be something we consider in the future, but I am curious how many projects you actually have in your solution.

By Randy Ayers - 5/6/2008

[b]Having an option may be something we consider in the future, but I am curious how many projects you actually have in your solution.

Currently, we have approximately 40 projects in the solution.  Only about a third of these contain BOs.

By Greg McGuffey - 5/6/2008

We generally break our solutions apart when they get to the 8 project level or so as many other things tend to slow down (just .NET IDE in general).




I know you covered this in class, but I recently tried it and no joy. The problem I was having is with dependencies. I'm having trouble figuring out how to break things up so they still compile, and it also helps me. Could you either go over this quickly or point me to a post that I'm forgetting on how to actually do this. An example might be useful:



SampleSolution

Project Dependencies

-------------- -----------------------

BaseProject -none-

BOProject BaseProject

UIProject BOProject, BaseProject

SecurityProject BOProject, BaseProject, UIProject

SharedModule BOProject, BaseProject, UIProject, SecurityProject

AppModuleOne BOProject, BaseProject, UIProject, SecurityProject

AppModuleTwo BOProject, BaseProject, UIProject, SecurityProject, SharedModule

AppModuleThree BOProject, BaseProject, UIProject, SecurityProject, SharedModule, AppModuleTwo

AppModuleFour BOProject, BaseProject, UIProject, SecurityProject, SharedModule, AppModuleTwo

AppExec BOProject, BaseProject, UIProject, SecurityProject, SharedModule, AppModuleOne-Four




Any suggestions would be helpful! Thanks!



(Sorry for the lame question...I'm still learning BigGrin)
By Trent L. Taylor - 5/6/2008

The problem I was having is with dependencies.

The key is not to use a project reference....that is why it breaks when you combine them into multiple solutions.  It is somewhat of a pros/cons type of approach.  What we do is have all of our application specific assemblies compile to the same output location, for example:

C:\Development\MyApplication Build

Then each of the projects reference the assembly in that build folder versus a project reference.  This will actually speed up your IDE as well...by a lot in some cases.  However, the downside is that when you right-click a class and choose "Go To Definition" it will not be able to if the class is in a different project.  But that is the only downside...which we decided wasn't too bad since generally you are doing this more often for classes within the same assembly.

Next, you will need to be sure and set your build order on your solution so that if you pull everything back down from source control...clear out the build folder, etc. it will build in the proper order so that when the dependent assemblies are built before they are needed as a reference, etc.

By Greg McGuffey - 5/6/2008

Thanks Trent. I'll chew on this for a bit...