On 2011-09-28 6:34 PM, Brett Porter wrote:
On 29/09/2011, at 4:04 AM, Eric Kolotyluk wrote:
OK, I did not have tlbimp.exe on my PATH, so I added it and made a little more
progress, but the build is still failing (see below).
I am not clear why there are complaints about missing assembly references. As
far as I can tell they seem to be there.
Part of the problems seems to be that
P:\Intersystem\main\platform.NET\intersystem-service\target\ does not have the
directory 28104638. Is this something that NPanday is supposed to create? Is
this because of the previous errors?
That's a temporarily generated directory that is removed again when the build
completes (Even on failure). You'll need to look at the response file while the
build is still going. I think if you run with -X it might show you what it is
putting into the response file, but I'd need to check.
Certainly something that could be improved on the npanday end to aid debugging.
- Brett
--
Brett Porter
[email protected]
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
OK, I was finally able to get this project to build :-)
If you use -X flag then the temporary directory is left behind so you
can inspect it. Nice feature.
Basically the compile was failing because of missing references. The
error message was misleading because (I think) the temporary directory
was being deleted too early due to the csc errors. I had to add a Maven
references for
<dependency>
<groupId>Microsoft.TeamFoundation.Common</groupId>
<artifactId>Microsoft.TeamFoundation.Common</artifactId>
<version>10.0.0.0</version>
<type>gac_msil</type>
<classifier>B03F5F7F11D50A3A</classifier>
</dependency>
<dependency>
<groupId>PresentationCore</groupId>
<artifactId>PresentationCore</artifactId>
<version>3.0.0.0</version>
<type>gac_32</type>
<classifier>31BF3856AD364E35</classifier>
</dependency>
The more subtle problem was a problem with one of the .dll files
generated in another Maven project. The problem here is that for some
reason the NPanday compile plugin insists on updating AssemblyInfo.cs,
but if that file is under source control then it is read only and it
fails to compile all the source files, however that actual build
succeeds so while there is a .dll artifact created, it is incomplete. So
basically
1. There seems to be a bug in the compile plugin where it is succeeding
when it should fail.
2. Trying to update AssemblyInfo.cs file is problematic with respect to
source control. The plugin should not update this file, rather it
should update one in the target directory. If there really is some
reason to update files that are likely under source control, then
the compile plugin needs to interact with the defined SCM.
Just one more .NET project to Mavenize...
Cheers, Eric
