So far, for my 6 years of programming, I've only used an interpreted language. That means, I have almost no experience with compilers. I've been using .NET 2003 for 2 years now, but have never ventured into the land of the command line compiler, I just always hit CTRL-F5. But, with my LLBLGen projects being the size that they are, I don't want to house them in my solution, so I want to use a command line compiler to rebuild them when I make changes.

So, I noticed that Frans uses NMAKE. I have attempted to learn from his examples, but I can't figure out how to include .cs files that are nested inside of directories (like EntityClasses or FactoryClasses). So, here so far is my attempt at making a "makeDAL" file which will then be my reference file to my "makeDal.cmd" file that uses the NMAKE builder.

SOURCES=AssemblyInfo.cs ConstantsEnums.cs .\EntityClasses\*.cs .\EntitySubClasses\*.cs .\FactoryClasses\*.cs

REFERENCES=SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll
REFDIR=C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11

all: $(SOURCES)
    csc /t:library /out:.\HLPUSD.SMART.DAL /d:TRACE /o /lib:$(REFDIR) /r:$(REFERENCES) $(SOURCES)

When I launch NMAKE (by calling my "makeDal.cmd" file) the compiler tells me it doesn't know how to make '.\EntitySubClasses*.cs' so obviously my SOURCE variable is not doing what I expect it to. How to I source all the files in those nested folders (inside the DatabaseGeneric folder) in my build script? Am I including all the necessary files? Is the ORMSupportClasses the only thing I need to reference for my DatabaseGeneric and DatabaseSpecific projects to compile? What would be hints for how to continue?

BTW - My poor attempt at copying Frans' code is no reflection on his abilities

NMake is pretty raw, it goes back to the horrible stone age dominated by the command line gdb and gnu make.

I use nmake because it lets me config several configurations in a config file like debug and release builds and also clean up code, though there are more ways to achieve the same goal. I use nmake also because nant, well.... , isn't my first choice . (somewhat slow and it was buggy, not anymore though).

nant is easier now, as it can consume a .sln file and you can build a solution with nant on the command line with a few lines of xml in a config file.

Making nmake check a recursive set of files, I'm not sure how to do that, though the MSDN library has a large set of helpfiles on nmake and nmake macro's (which is what you need )

The csc compiler is a bit silly in this, you need to specify /recurse:*.cs as the source input for csc. See: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=242

After trying several build tools, I found that using VS itself is most productive. The issue about big solutions can be solved by structuring your solutions: 1- One solution to house the DAL projects and generate the DAL dlls 2- One solution to house my BL and UI projects (both of which reference the DAL.Generic dll while the BL also references the DAL.DBSpecific dll) Structuring my work like this allowed me to use VS in a 300+ table project with ease.

<mostly useless information>

Some of my DotNetNuke solutions have 20+ projects in them including the DAL.

Our biggest solution has 48 projects, and we reference the GenPro DAL as compiled assemblies so that doesn't count. What's worse I think some of the projects need splitting in two...

I feel like I should split that monster in three... cheers alvaro.-

I've found FinalBuilder to be a fantastic tool, albeit not free...

Jeff...

omar wrote:

After trying several build tools, I found that using VS itself is most productive. The issue about big solutions can be solved by structuring your solutions: 1- One solution to house the DAL projects and generate the DAL dlls 2- One solution to house my BL and UI projects (both of which reference the DAL.Generic dll while the BL also references the DAL.DBSpecific dll) Structuring my work like this allowed me to use VS in a 300+ table project with ease.

We do the same thing and it has worked out well so far.

alexdresko wrote:

Some of my DotNetNuke solutions have 20+ projects in them including the DAL.

Wow

How long does that take to compile? I'd like to hear more about your adventures with DotNetNuke and LLBL... if you don't mind!

When we started building our company's ERP, we found it logical to split the various functional modules into separate projects. The reasoning was that this is more team-development friendly. After struggling with versioning and circular-reference issues for 8 months, we came to one conclusion. This is no way friendly on natural!!. LLBL helped greatly in further simplifying our projects. I would be really interested to learn why would LLBL developers opt (or be forced to) break their BL into several projects.

NOTE: we opted to FinalBuilder at one stage and it is a great build tool, but then our two-projects solution was very easy to handle with VS and a couple of batch-files.

I split our projects up into 3 solutions and use the build rules functionality to achieve what we want.

We have a DB project which is totally the LLBLGen generated code, the build rule for this runs a batch file after successful compile to copy the output to a references folder of the appropriate version (we use seperate folders for different versions).

The BL (Business Logic) solution has all of our business managers and user controls defined within with references to the compiled output in our reference folder and again uses Build Rules to copy out to a references folder.

The last solution is the actual application, which contains references to the previous reference folders and really has no code other than instantiating our framework and initiating a call into the managers.

This works great for us, as we have a single DB project that anyone can check out add tables, procs, views etc. Compile and check back in, it is rarely checked out for more than 15 minutes at a time.

The BL is checked out by many developers, but they only check out the individual manager or user control they are currently working on.

And typically only 1 person has the application they are working on checked out since it isn't much more than a base framework that calls into the managers, very little code is actually here.

With this we reuse the db in all projects, and the managers over many projects, the only time we don't have perfect reuse is when we have to do com interop for legacy VB6 code to call the new .NET stuff, but that is minimal.

John

I use NAnt. Never had a problem with it. The only problem I have with it is the team makes breaking changes between RC1 and RC2... for geeze sakes, just release it will ya.

Anyway, it has always been able to do what we needed, and I have not yet needed to create my own task. Between the build in tasks and contrib tasks there is not much you can ask for.

Also, at the time I started using it there was no PVCS Version manager tasks, so I just used the command line interface and use the EXEC task.

As far as it being slow, well I'm not sure I see this. It is just calling out to CSC or whatever. Although, I have to admit, the build server runs the builds at 11PM, so it doesn't really matter to much, as long as the build is done by the morning.

BOb

Bashar wrote:

alexdresko wrote:

Some of my DotNetNuke solutions have 20+ projects in them including the DAL.

Wow

How long does that take to compile? I'd like to hear more about your adventures with DotNetNuke and LLBL... if you don't mind!

Compile time varies greatly depending upon how you work in a solution that big. The most important thing is knowing when to use 'Build Solution', 'Rebuild Solution', Build <project>, Rebuild <project>. Rebuliding the entire solution every time just isn't necessary and wastes time. A full recompile on my 3Ghz/512 RAM/80GB 7200RPM laptop usually takes about 30-60 seconds. A simple build of a single module takes about 6-15. On my newer DNN v3.1 based solutions, I don't have to include any of the DNN related projects (google: Speerio mymodules).

Using LLBLGen with DNN is very straight forward. It takes longer to understand the DNN code base than it does LLBLGen IMO. That has lot to do with the fact that DNN is open source.

I've got a custom DNN installation and script that creates the IIS site, SQL database, DNS entries and sets the connection string. It takes about 30 minutes to properly set up my development environment including making sure that I can successfully recompile the DNN core projects. I now have my own custom DNN module templates for VS.NET 2003 so creating new modules or usercontrols takes about 2 seconds. I'm quite proud of my VS.NET templates because they add all the referenes I need to the projects and code behind files. It even addsa log4net instance to each page.

I just created a pretty nice 3 module reporting set for a new customer in 25 hours using all that custom stuff, LLBLGen and Infragistics controls.

pilotboba wrote:

I use NAnt. Never had a problem with it. The only problem I have with it is the team makes breaking changes between RC1 and RC2... for geeze sakes, just release it will ya.

Anyway, it has always been able to do what we needed, and I have not yet needed to create my own task. Between the build in tasks and contrib tasks there is not much you can ask for.

Also, at the time I started using it there was no PVCS Version manager tasks, so I just used the command line interface and use the EXEC task.

As far as it being slow, well I'm not sure I see this. It is just calling out to CSC or whatever. Although, I have to admit, the build server runs the builds at 11PM, so it doesn't really matter to much, as long as the build is done by the morning.

Compilation is of course done by the csc/vbc compilers, so that's the same, though when you compile an application with a lot of resources (like a winforms app), the resource compilation with nant is slower than with vs.net for example.

I use finalbuilder to build all systems and create installers etc. (which calls into command line builds sometimes. I already had those, and they work fine so I kept those).

I use a small system with a database to log changes per project / category. (using a winforms app) This then sets flags per project/category if it has changed. The finalbuilder project has a custom task in C# which reads the flags out and sets finalbuilder variables. Per project/category I made a group in the project and it builds the group if the corresponding flag is set. At the end I reset the flags.

So I fix a bug, log the bug in the bugtracker, make a log in my log program, then start final builder and run the project. It builds all the elements required (so a fix in a driver, also automatically builds a new SDK for example, as the source changed ) and creates zip files, complete with readme's, which contain the latest changes exported from my log database. I then just have to ftp the files to the webserver and in the CMS to update some items and that's it