Last post Apr 21, 2010 09:44 AM by atconway
Oct 12, 2009 10:43 AM|alexjamesbrown|LINK
I'm currently in the process of developing a large application. At the moment, i have one solution (this may change in the fullness of time) with many projects.
I've set up the directory structure as:
\ lib\ (contains shared 3rd party components) build\ build\bin (output directory) build\wwwroot (output directory for web app) config\ ) src\ (contains the folders for the below projects)
On each of the projects, I have set the build location (output directory) to "..\build\bin\" This, as illustrated above, makes the projects build into build\bin, above the src directory. On
Company.Entities References Company.Common This has all the business objects (customer, order, product) etc....
Company.Common Contains classes that format strings, dates, file access etc.... Doesn't contain any references to any other of the Company. libraries.
Company.Data References 3rd party lib (Castle Windsor for example) This contains interfaces like IRepository, ICustomerRepository, IOrderRepository etc.... Has RepositoryFactory class - this has a method called "Get()" which uses Ioc (Castle
Windsor) to return the Also contains IoC for resolving the current implementations of these repositories. Castle.config is in the \config\ directory - and included "as a link" in this project. I've set it to always copy to the output directory
Company.Data.LinqToSql References Company.Data This is the current data access library. It's instantiated by IoC
Company.Logic References to Company.Data Business logic layer - has methods like GetProductById(string id) - this in turn calls Repository.Get().GetById(id) - for example
Company.Tests Self explanatory... will make more use of this in the future.
Company.Web References Company.Logic, Company.Entities, Company.Common Web UI layer - this is the main website.
Ok, hopefully that gives you a little background into the current architecture of my projects etc...
Currently, I'm building everything into thie build/bin directory, except for Company.Web, which builds into build/wwwroot (this adds a bin directory in there) I then have a post-build event that copies aspx pages, style sheets, images, js files etc.... from
the src/Company.Web location to build/wwwroot I've configured Visual Studio to use IIS for debugging, and set up an iis virtual directory to point to my build/wwwroot folder.
However... Certain required files are not built into the wwwroot/bin directory Such as - Company.Data.LinqToSql - since this isn't referenced by proejcts, but instantiated using IoC
How can I improve my Build process / project structure to help me with my development? I will "thumb up" all sensible suggestions.
Apr 21, 2010 07:03 AM|bespoke_web_developer|LINK
I can just suggest that you read up on Cruise Control.
It's really helpful with large scale projects - it builds your projects in the background as you develop and you can view the latest successfull version at anytime.
Apart from that - try to break your solution into as many projects as logical (each in it's own unit)
This will improve performance when you compile since you only compile the project that you've modified since the last build.
hope it helps
Apr 21, 2010 09:44 AM|atconway|LINK
I don't think the 'physical' location of output files is near as important as the logical structure of an application regardless of size. In your case you have a well laid out logical structure (which by the way is normally the much more difficult part),
but then added complexity by manually reconfiguring where the built output files are located (ie. build/bin, build/wwwroot, etc.). Unless you are physically going to separate components onto different servers, why not just have the entire solution and associated
references build into the default /bin directory? Then upon Publish, Copy, etc. all of your needed files will be there. In your case you are going to have to mess with the 'Copy Output' settings or add a reference in the UI level to LinqToSQL so it can be
used by IoC just to satisfy the needs of the modified output structure. .NET is smart enough to add to the /bin references needed within a built binary, but your structure seems to be interfering with this. And honestly I don't believe there is any type
of performance gain or advantage to reworking the output of your binaries; typically it just causes issues like the one you have encountered.