Automated build issues: Advice please

[Kyle Baley]

Wanted to get some thoughts on how to address some issues I'm having with creating an automated build (with NAnt). The build file calls msbuild against the .sln file and some of the issues could possibly be resolved if I instead called csc.exe directly and compiled everything into a single assembly.

 

Here is the task that compiles (for reference):

 

 <target name="compile" depends="init">
  <exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe"
      commandline="${solution.file} /t:Clean /p:Configuration=${project.config};SolutionDir=${current.dir} /v:q" workingdir="." />
  <exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe"
      commandline="${solution.file} /t:Rebuild /p:Configuration=${project.config};SolutionDir=${current.dir} /v:q" workingdir="." />
 </target>
 

 The first issue I had was that it couldn't find project references. This was a strange one. I had to drop and re-add all the project references to get it to work. The issue was that the GUIDs for the projects didn't match. For example, the Data project had a reference to the Core project. In the .csproj file, the ItemGroup was referencing the Core project but the GUID didn't match. Perhaps that's a side effect of the scaffolding but the question is: If msbuild can't find the references, how does Visual Studio do it? I thought VS just called out to msbuild.

 

The second problem is one I'm currently trying to work out. The Tests project uses its own NHibernate config file to do tests against an in-memory database. But the mapping integration tests use the same config file as the web application. During my build, I'm dumping everything into a single directory and performing the tests there. Which is an issue because I need to reference two different config files. Plus there's the fact that the integration test has a hard-coded path to the Web project's config file.

 

There are a couple of ways i can think of that could fix this. One is to have a separate project for unit tests and integration tests. Another is to create the NHibernate configuration programmatically for the SQLite tests (as shown here: http://ayende.com/Blog/archive/2006/10/14/UnitTestingWithNHibernateActiveRecord.aspx).

 

And the over-arching question: is this a S#arp issue or an individual project issue? I.e. Should S#arp be changed so that the NHibernate configuration is managed by a separate component? One that either reads from a file or has it done programmatically? At first glance, that seems like overkill but maybe not.

[Simone Busoli]

inline

On Tue, Jan 6, 2009 at 4:25 PM, Kyle Baley <ky...@baley.org> wrote:

Wanted to get some thoughts on how to address some issues I'm having with creating an automated build (with NAnt). The build file calls msbuild against the .sln file and some of the issues could possibly be resolved if I instead called csc.exe directly and compiled everything into a single assembly.

 

Here is the task that compiles (for reference):

 

 <target name="compile" depends="init">
  <exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe"
      commandline="${solution.file} /t:Clean /p:Configuration=${project.config};SolutionDir=${current.dir} /v:q" workingdir="." />
  <exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe"
      commandline="${solution.file} /t:Rebuild /p:Configuration=${project.config};SolutionDir=${current.dir} /v:q" workingdir="." />
 </target>
 

 The first issue I had was that it couldn't find project references. This was a strange one. I had to drop and re-add all the project references to get it to work. The issue was that the GUIDs for the projects didn't match. For example, the Data project had a reference to the Core project. In the .csproj file, the ItemGroup was referencing the Core project but the GUID didn't match. Perhaps that's a side effect of the scaffolding but the question is: If msbuild can't find the references, how does Visual Studio do it? I thought VS just called out to msbuild.

I too had issues with Visual Studio doing different things with the solution compared to msbuild, but didn't investigate much and can't say what's going on.

 

 

The second problem is one I'm currently trying to work out. The Tests project uses its own NHibernate config file to do tests against an in-memory database. But the mapping integration tests use the same config file as the web application. During my build, I'm dumping everything into a single directory and performing the tests there. Which is an issue because I need to reference two different config files. Plus there's the fact that the integration test has a hard-coded path to the Web project's config file.

 

There are a couple of ways i can think of that could fix this. One is to have a separate project for unit tests and integration tests. Another is to create the NHibernate configuration programmatically for the SQLite tests (as shown here: http://ayende.com/Blog/archive/2006/10/14/UnitTestingWithNHibernateActiveRecord.aspx).

I use to separate the unit and integration test projects, but using a base test class which configures NHibernate programmatically is another way to go. I'm not sure how well it integrates with Fluent NHibernate though.

 

 

And the over-arching question: is this a S#arp issue or an individual project issue? I.e. Should S#arp be changed so that the NHibernate configuration is managed by a separate component? One that either reads from a file or has it done programmatically? At first glance, that seems like overkill but maybe not.

Actually, I think that having a way to either set up NHibernate via configuration or programmatically should be trivial, it's something we should consider doing.

 

[Luis Abreu]

Interesting….I haven’t had any problems on my projects in these last months. I’m using cc.net and I’m using msbuild directly against the sln file without any problems regarding dependencies (I’m talking about solutions that have several projects, none of which is a MVC web project). If I recall correctly, the only problem I had was that by default I was getting msbuild from .net 2.0 instead of the on from 3.5…

 

Regarding the NH configuration, I’ve used both approaches and now I try to stick with the code approach….

 

---

Luis Abreu

[Kyle Baley]

Ya, I'm using TeamCity with an MVC app, though it's not a S#arp one. In fact, it was that app that gave me the build file I started with for this. It works fine for that app but not so much for the S#arp one, at least until I fixed the references.

[Simone Busoli]

I'm going to commit a slight modification to the NHibernateSession class which accepts a dictionary for the properties to configure NHibernate.

[Kyle Baley]

I haven't checked recently but does Fluent NHibernate have an interface for initializing the session?

[Billy]

Simone,

Is this going to be an overload or a breaking change?

Billy

On Jan 6, 9:13 am, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> I'm going to commit a slight modification to the NHibernateSession class
> which accepts a dictionary for the properties to configure NHibernate.
>

> On Tue, Jan 6, 2009 at 5:10 PM, Kyle Baley <k...@baley.org> wrote:
> > Ya, I'm using TeamCity with an MVC app, though it's not a S#arp one. In
> > fact, it was that app that gave me the build file I started with for this.
> > It works fine for that app but not so much for the S#arp one, at least until
> > I fixed the references.
>
> > On Tue, Jan 6, 2009 at 11:05 AM, Luis Abreu <lab...@gmail.com> wrote:
>
> >>  Interesting….I haven't had any problems on my projects in these last
> >> months. I'm using cc.net and I'm using msbuild directly against the sln
> >> file without any problems regarding dependencies (I'm talking about
> >> solutions that have several projects, none of which is a MVC web project).
> >> If I recall correctly, the only problem I had was that by default I was
> >> getting msbuild from .net 2.0 instead of the on from 3.5…
>
> >> Regarding the NH configuration, I've used both approaches and now I try to
> >> stick with the code approach….
>
> >> ---
>
> >> Luis Abreu
>

> >> *From:* sharp-arc...@googlegroups.com [mailto:
> >> sharp-arc...@googlegroups.com] *On Behalf Of *Simone Busoli
> >> *Sent:* terça-feira, 6 de Janeiro de 2009 15:39
> >> *To:* sharp-arc...@googlegroups.com
> >> *Subject:* Re: Automated build issues: Advice please
>
> >> inline

> >>http://ayende.com/Blog/archive/2006/10/14/UnitTestingWithNHibernateAc...
> >> ).

[Simone Busoli]

An overload of the Init method on the NHibernateSession class.

@Kyle: yes, I realized that it provides an extension method on the NH Configuration class.

[alberto rodriguez]

Yeah, I had the issue with the guid's at work not too long ago. The
way VS builds the solution is a mistery to me. If you look at the
output windows while compiling you'll see it calls csc, but I don't
know how it gets the dependencies solved, then.

Re the hard-coded path, maybe adding the config file as a link would
help?

Kyle Baley ha escrito:

[Simone Busoli]

For the records, the issue I was talking about with VS doing something different from msbuild from the command line is that if the solution doesn't contain any .NET code (and maybe something mysterious I am missing), msbuild will fail to build the project, while VS will do that just fine. I think it's a bug which has been around at least since 2006.

[tom]

I had a problem getting msbuild to get a working build on the s#arp
solution file. It turned out the GUID's for the project references
were not correct for some reason. Even though it would build just
fine in VS2008. To fix this issue I just removed project references
from each project, and re added them. It seemed to have resync'd the
project GUIDs and everything has worked great since.

On Jan 8, 3:42 pm, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> For the records, the issue I was talking about with VS doing something
> different from msbuild from the command line is that if the solution doesn't
> contain any .NET code (and maybe something mysterious I am missing), msbuild
> will fail to build the project, while VS will do that just fine. I think
> it's a bug which has been around at least since 2006.
>
> On Thu, Jan 8, 2009 at 8:19 PM, alberto rodriguez

> <alberto.em...@gmail.com>wrote:

> >http://ayende.com/Blog/archive/2006/10/14/UnitTestingWithNHibernateAc...

[Billy]

Hi Tom,

This is a known issue (http://code.google.com/p/sharp-architecture/
issues/detail?id=53) and one that has given me quite a headache. The
crux of the problem is that it's difficult to share GUIDs across
projects generated with Visual Studio template files. (The whole VS
templating system is quite limiting IMO if you're generating a
solution with multiple projects.) Regardless, I'll have this resolved
before 1.0.

Billy

[Jonathan Parker]

You've probably both used NAnt before but I thought I may as well,
just in case, send through a build file that I've used in the past.
Nothing special but could be used as a starting point if no-one has
anything handy.

I've just "genericised" it though so it's untested and will need some tweaking.

See attached file.

Cheers,
Jonathan.

ed

[tom]

Billy,

One way to get around this that I could think of is to do the
following.

1. Create a folder at the root of the solution directory that could
hold all the assemblies being build (call it SharedAssemblies for now)
2. Make the post build event of each project copy its DLL, pdb, etc
into that folder
3. Each project can reference the other through that folder. It will
be a relative 'HintPath' so it should work right out of the box for
the template (I think).

This would totally avoid any need to reference based on a GUID that
seems to change when you build the template. Just my 2 cents I felt
the need to share :)

[Billy]

Thanks for the script Jonathan! I'll look it over for ideas that I
haven't used in the past.

Billy

On Feb 25, 12:49 am, Jonathan Parker <jonathanparkerem...@gmail.com>
wrote:

>  genericbuildfile.build
> 6KViewDownload

[Billy]

Hi Tom,

That would be an OK last resort option; the problem is that you still
wouldn't be able to "go to definition" from one project to another
without getting a read-only metadata view of the definition. That's
the benefit of consistent GUIDs.

Billy