[nant-dev] Compiling vbproj getting a CLSCompliant error from vbc - have workaround
Hi all, Have been sucessfully using Nant to compile c# project for month now with no issues. However I now have a need to compile a VB project, so I was hoping it would be just as simple as C# Nant build process. However. I've stumbled across the following error during the vbc compile: [vbc] Starting 'C:\WINNT\Microsoft.NET\Framework\v1.0.3705\vbc.exe (@"C:\DOCUME~1\xxx\LOCALS~1\Temp\tmp2B0.tmp")' in 'c:\nant\dataaccess' c:\nant\dataaccess\AssemblyInfo.vb(16) : error BC30002: Type 'CLSCompliant' is not defined. Assembly: CLSCompliant(True) BUILD FAILED Version info: NET Framework - v1.0.3705 NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 26/12/2003) According to .NET Class lib help, "CLSCompliant" is ref'ed in Mscorlib (in Mscorlib.dll) which is covered by the inclusion of system.dll in the .build by the following: references includes name="System.dll" / includes name="System.Data.dll" / includes name="System.Xml.dll" / /references I've tried directly including "Mscorlib.dll" in the references but the vbc ignores it - "'mscorlib.dll' has already been automatically added; ignored" I managed to identify a work-around by removing (commenting out) "Assembly: CLSCompliant(True) " in the AssemblyInfo.vb. However I'm a little worried about excluding the CLSCompliant Attribute as this may cause CLS-compliant issues if I ever need to integrate with CLS-compliant assembles in the future. Can anyone provide any comments or a fix for my .build to resolve the issue? Thanks in advance. Cheers, Chris
Re: [nant-dev] Compiling vbproj getting a CLSCompliant error from vbc - have workaround
Chris, Are you sure you've imported the System namespace ? Gert - Original Message - From: Chris Hill [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 16, 2004 11:03 AM Subject: [nant-dev] Compiling vbproj getting a CLSCompliant error from vbc - have workaround Hi all, Have been sucessfully using Nant to compile c# project for month now with no issues. However I now have a need to compile a VB project, so I was hoping it would be just as simple as C# Nant build process. However. I've stumbled across the following error during the vbc compile: [vbc] Starting 'C:\WINNT\Microsoft.NET\Framework\v1.0.3705\vbc.exe (@C:\DOCUME~1\xxx\LOCALS~1\Temp\tmp2B0.tmp)' in 'c:\nant\dataaccess' c:\nant\dataaccess\AssemblyInfo.vb(16) : error BC30002: Type 'CLSCompliant' is not defined. Assembly: CLSCompliant(True) BUILD FAILED Version info: NET Framework - v1.0.3705 NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 26/12/2003) According to .NET Class lib help, CLSCompliant is ref'ed in Mscorlib (in Mscorlib.dll) which is covered by the inclusion of system.dll in the .build by the following: references includes name=System.dll / includes name=System.Data.dll / includes name=System.Xml.dll / /references I've tried directly including Mscorlib.dll in the references but the vbc ignores it - 'mscorlib.dll' has already been automatically added; ignored I managed to identify a work-around by removing (commenting out) Assembly: CLSCompliant(True) in the AssemblyInfo.vb. However I'm a little worried about excluding the CLSCompliant Attribute as this may cause CLS-compliant issues if I ever need to integrate with CLS-compliant assembles in the future. Can anyone provide any comments or a fix for my .build to resolve the issue? Thanks in advance. Cheers, Chris --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: Two broken testcases - edge case question
Troy Laurin wrote:
Matthew,
The new behaviour more closely follows the documentation, and as you say
this becomes consistent with handling of files... but any build files
relying on the old behaviour will of course break.
The fix is simple, to replace **/* with */**/*, but it may be hard
to diagnose if/when upgrading breaks your build script...
Yeah - it's tricky to determine if this is a problem or not. It's such
a strange pattern to use (it only appeared in a testcase).
A note on your previous email...
2. foo/**/*.cs was being converted to foo/(^\\.*)*/[^\\]*.cs This
is now converted to foo/\\?.*[^\\]*.cs, also much faster.
foo/(^\\.*)*/[^\\]*.cs
Looking at the code for DirectoryScanner, how is it possible for this to
be produced? On windows, I get foo(\\.*)*\\[^\\]*\.cs. From looking
at the code, on unix/linux I would expect to get foo(/.*)*/[^/]*\.cs.
The conversion result would then be foo.*/[^/]*\.cs, which appears to
give exactly the same results.
Note that my message here is out of sync with current CVS until I get it
working. :)
Also note that all my assertions were backed up by profiling/timing a
test application with the given regexes.
It's faster to scan for single characters, rather than a repeating
group. I don't know how this is implemented internally, but profiling
(and my suspicions initially) figured that it would be easier to scan
using straight patterns rather than a pattern than requires nested
pattern scanning (ie: the repeating group with negation).
I'm curious that taking out the ^$ anchors speeds up the search, since
there's an explicit comment in the DirectoryScanner source noting that
they are added to improve the speed... and it makes sense that including
them would reduce the amount of stringspace that would need to be
examined by the regular expression... then again, I haven't tried
comparing the speed of each regular expression, so I'm happy to accept
that my understanding might be flawed :-)
If you are searching for an entire string, anchoring is faster. For
instance, if you are searching for blah foo bar in the string blah
foo bar, anchoring will be the fastest way to find it.
It turns out to be slower to search for this pattern:
$.*blah foo bar.*^
than for this pattern:
blah foo bar
I'm only removing anchors if they conflict with wildcards, since the
regex engine can terminate early in the latter pattern, while it needs
to scan to the end of the string in the former.
A couple of extra comments on DirectoryScanner...
Both the ToRegexPattern and ParseSearchDirectoryAndPattern methods
perform slash replacement. ToRegexPattern is private, and only called
from ParseSearchDirectoryAndPattern, so should be able to assume that
slashes are already replaced.
Sounds good to me. I'll have to take a look to see if I can remove the
extra replacement.
Just being picky, but shouldn't 'if (s.Length == 2 s[1] ==
Path.VolumeSeparatorChar) {' be 'if
(s.EndsWith(Path.VolumeSeparatorChar)) {'? This allows for platforms
that support named volumes, as well as just drive letters. Not that
there are any platforms like this around any more :-)
Seeing as how Path.VolumeSeparatorChar is a char, our current
comparison will support all possible return values. ;)
Thanks for the note,
Matt.
Regards,
-- Troy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Mastracci
Sent: Thursday, 8 July 2004 5:34 AM
To: Nant-Developers (E-mail)
Subject: [nant-dev] Two broken testcases - edge case question
It looks like the regex optimization broke an edge case:
**/* now matches the base directory, as well as any
subdirectories on a FileSet.DirectoryNames call. For
instance, in the following directory structure, all three
will be matched with a base directory of C:\foo:
C:\foo
C:\foo\bar
C:\foo\baz
The old behaviour would only match the two subdirectories.
Is this behaviour important to anyone? This is actually more
consistent, considering that:
file/**/*.cs
matches:
file/bar.cs
file/foo/bar.cs
file/foo/foo/bar.cs
**/ can basically be considered to be current directory or
subdirectories.
Matt.
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor
pitches, unmatched networking opportunities. Visit
www.blackhat.com ___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Disclaimer Message:
This message contains confidential information and is intended only for the
individual(s) named. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please immediately delete it and all copies of it from
your system, destroy any hard copies of it, and notify the sender. E-mail transmission
cannot be guaranteed to
Re: Fw: [nant-dev] current cvs build failure
Managed to reproduce this issue by building on a different drive with the path "Z:\cvs\nant\..." Looks like the "**/CVS/**" pattern is matching the \cvs\ bit in the pathname. There's an implicit rule in NAnt that the include/exclude patterns only apply to the part of the path added after the base directory. The old (and currently correct) behavior is to test the pattern appended to the root path: ^Z:\cvs\nant\(some wildcard pattern)$ The new behaviour optimized this to just (some wildcard pattern) Of course, this new behaviour will break anything under a "cvs/" directory. What should happen in this following case with the implicit "**/CVS/**" rule? Is this even valid? fileset basedir="C:\extra-build" includes name="C:\cvs\nant\**\*.cs" / includes name="*.cs" / /fileset Matt. Gert Driesen wrote: - Original Message - From: "Ian MacLean" [EMAIL PROTECTED] To: "Matthew Mastracci" [EMAIL PROTECTED] Cc: "Gert Driesen" [EMAIL PROTECTED] Sent: Friday, July 09, 2004 4:12 AM Subject: Re: Fw: [nant-dev] current cvs build failure Matthew Mastracci wrote: Strange - I had the same issue while I was developing (turned out that the DirectoryScanner was busted), but the fix for that was checked in. Where was the fix ? Maybe its manifesting itself in another way on my machine setup I can reproduce it here too. For now, I've reverted DirectoryScanner.cs back to 1.33. Gert begin:vcard fn:Matthew Mastracci n:Mastracci;Matthew org:aclaro Softworks, inc. adr:;;1900 a - 11 St. SE;Calgary;Alberta;T2H 3G2;Canada email;internet:[EMAIL PROTECTED] title:Software Developer tel;work:(403) 299-6612 x-mozilla-html:FALSE url:http://www.aclaro.com version:2.1 end:vcard
Re: Fw: [nant-dev] current cvs build failure
After short consideration, I suppose the following rules apply (and should be documented): If a pattern is not rooted, it implicitly applies only to files and directories gathered from non-rooted include patterns and only to the segment of the path after the base directory segment. For instance, if the base directory is "C:\cvs\foo\bar\" and the pattern is "**/CVS/**", the pattern will only be tested against the filenames relative to the C:\cvs\foo\bar directory. C:\cvs\foo\bar\xxx\x.cs will be tested as "xxx\x.cs" against the pattern ".*/CVS/.*". Note that the this rule will disable "**/CVS/**" checking in absolutely-specified paths (do we allow check this now?). One question: how do patterns specified using ".." work? * Note: "frompath" patterns could be a special case of the above where the base directory is set to each of the path elements and searched as above. If a pattern is rooted, it is tested against the entire path string. If the full pattern path happens to correspond to the base directory, it may apply to files beneath the base directory. We should probably document the "defaultincludes" boolean flag as well. ;) Matthew Mastracci wrote: Managed to reproduce this issue by building on a different drive with the path "Z:\cvs\nant\..." Looks like the "**/CVS/**" pattern is matching the \cvs\ bit in the pathname. There's an implicit rule in NAnt that the include/exclude patterns only apply to the part of the path added after the base directory. The old (and currently correct) behavior is to test the pattern appended to the root path: ^Z:\cvs\nant\(some wildcard pattern)$ The new behaviour optimized this to just (some wildcard pattern) Of course, this new behaviour will break anything under a "cvs/" directory. What should happen in this following case with the implicit "**/CVS/**" rule? Is this even valid? fileset basedir="C:\extra-build" includes name="C:\cvs\nant\**\*.cs" / includes name="*.cs" / /fileset Matt. Gert Driesen wrote: - Original Message - From: "Ian MacLean" [EMAIL PROTECTED] To: "Matthew Mastracci" [EMAIL PROTECTED] Cc: "Gert Driesen" [EMAIL PROTECTED] Sent: Friday, July 09, 2004 4:12 AM Subject: Re: Fw: [nant-dev] current cvs build failure Matthew Mastracci wrote: Strange - I had the same issue while I was developing (turned out that the DirectoryScanner was busted), but the fix for that was checked in. Where was the fix ? Maybe its manifesting itself in another way on my machine setup I can reproduce it here too. For now, I've reverted DirectoryScanner.cs back to 1.33. Gert begin:vcard fn:Matthew Mastracci n:Mastracci;Matthew org:aclaro Softworks, inc. adr:;;1900 a - 11 St. SE;Calgary;Alberta;T2H 3G2;Canada email;internet:[EMAIL PROTECTED] title:Software Developer tel;work:(403) 299-6612 x-mozilla-html:FALSE url:http://www.aclaro.com version:2.1 end:vcard
[nant-dev] error message
Any help with this? Target(s) specified: self-userdoc self-userdoc: BUILD FAILED INTERNAL ERROR NDoc.Core.DocumenterException: Error reading in project file C:\DOCUME~1\ROONEY~ 1.8VL\LOCALS~1\Temp\tmpC5.tmp. Object reference not set to an instance of an object. --- System.NullReferenceE xception: Object reference not set to an instance of an object. at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvid er provider) at NDoc.Core.BaseDocumenterConfig.Read(XmlReader reader) at NDoc.Core.Project.ReadDocumenters(XmlReader reader) at NDoc.Core.Project.Read(String filename) --- End of inner exception stack trace --- at NDoc.Core.Project.Read(String filename) at NAnt.DotNet.Tasks.NDocTask.ExecuteTask() at NAnt.Core.Task.Execute() at NAnt.Core.Target.Execute() at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) at NAnt.Core.Project.Execute() at NAnt.Core.Project.Run() Please send bug report to [EMAIL PROTECTED] Total time: 0.2 seconds.
[nant-dev] MSI task exception and help needed
All,
Im trying to create an MSI using the msi
task. I got the most recent nightly nant build (7/17/2004).
The build generated this exception:
System.ArgumentException:
Version conflict with ResourceManager .resources files! Expected version:
1 but got: 2
Besides the exception that I got, I could use some help with
the msi task. The 5/25 build doesnt like the task elements.
My build target and msi task is shown below.
I want to create a very simple MSI for deployment to some
web servers.
After my build runs, I have the following directory
structure
V1.0.3.4\Storefront
V1.0.3.4\CatalogManager
V1.0.3.4\GAC-Installs
V1.0.3.4\Profiles
V1.0.3.4\WebServices
The deployment is almost a straight copy to the following
directories:
D:\inetpub\wwwroot-storefront\Storefront
D:\inetpub\wwwroot-storefront\CatalogManager
D:\inetpub\wwwroot-storefront\WebServices
C:\Program
Files\ITBAS\Profiles
Install
all files from the GAC-Installs directory into the GAC.
The person installing the MSI shouldnt be allowed to
change locations or installed components.
Any help would be much appreciated. Ive never
created an MSI before.
Thanks,
Noel
C:\Projects\Storefront-CInant\bin\nant
/f:Test.build MSI
NAnt 0.85 (Build 0.85.1659.0; net-1.0.win32; nightly; 7/17/2004)
Copyright (C) 2001-2004 Gerry Shaw
http://nant.sourceforge.net
Buildfile: file:///C:/Projects/Storefront-CI/Test.build
Target(s) specified: MSI
MSI:
Build failure
INTERNAL ERROR
System.ArgumentException: Version conflict with ResourceManager .resources
files! Expected version: 1 but got: 2
at System.Resources.ResourceReader.ReadResources()
at System.Resources.ResourceReader..ctor(Stream stream, Hashtable
table)
at System.Resources.RuntimeResourceSet..ctor(Stream stream)
at System.Resources.ResourceManager.CreateResourceSet(Stream
store)
at
System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean
createIfNotExists, Boolean tr
yParents)
at
System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture,
Boolean createIfNotExists, Boolean tr
yParents)
at
System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture,
Boolean createIfNotExists, Boolean tr
yParents)
at System.Resources.ResourceManager.GetString(String name,
CultureInfo culture)
at System.Resources.ResourceManager.GetString(String name)
at NAnt.Contrib.Tasks.SchemaValidatedTask.InitializeTask(XmlNode
TaskNode) in C:\Documents and Settings\drieseng\Loca
l Settings\Temp\tmp11F4.tmp\src\Tasks\SchemaValidatedTask.cs:line 99
at NAnt.Contrib.Tasks.Msi.MsiTask.InitializeTask(XmlNode TaskNode)
in C:\Documents and Settings\drieseng\Local Settin
gs\Temp\tmp11F4.tmp\src\Tasks\Msi\MsiTask.cs:line 353
at NAnt.Core.Task.InitializeElement(XmlNode elementNode) in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src\NAnt.Co
re\Task.cs:line 407
at NAnt.Core.Element.Initialize(XmlNode elementNode, PropertyDictionary
properties, FrameworkInfo framework) in C:\DO
CUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src\NAnt.Core\Element.cs:line 272
at NAnt.Core.Element.Initialize(XmlNode elementNode) in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src\NAnt.Core\E
lement.cs:line 192
at NAnt.Core.Project.CreateTask(XmlNode taskNode, Target target)
in C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src
\NAnt.Core\Project.cs:line 1003
at NAnt.Core.Target.Execute() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src\NAnt.Core\Target.cs:line 247
at NAnt.Core.Project.Execute(String targetName, Boolean
forceDependencies) in C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA
66.tmp\src\NAnt.Core\Project.cs:line 876
at NAnt.Core.Project.Execute() in C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src\NAnt.Core\Project.cs:line
833
at NAnt.Core.Project.Run() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmpA66.tmp\src\NAnt.Core\Project.cs:line 903
Please send bug report to [EMAIL PROTECTED]
Total time: 1.7 seconds.
target name=MSI
msi
output=C:\Projects\V1.0.4.17.msi
sourcedir=C:\Projects\V1.0.4.17 verbose=true
features
feature name=StorefrontProject display=1
title=All of Storefront typical=true
directory=C:\Projects\V1.0.4.17\Storefront
attr=16 /
/features
components
component name=D_Storefront feature=StorefrontProject
directory=D:\inetpub\wwwroot-storefront\Storefront
id={000F93F1-30E8-48E2-ABB2-96D4CEC8202E} attr=0
installassembliestogac=false
key file=default.aspx /
fileset basedir=D:\inetpub\wwwroot-storefront\Storefront
include name=**\*.* /
/fileset
/component
component
name=D_CatalogManager feature=StorefrontProject
directory=D:\inetpub\wwwroot-storefront\CatalogManager
id={C61BCC71-9315-4EAE-AC66-589ABD0E2379} attr=0
installassembliestogac=false
key
file=default.aspx /
fileset
basedir=D:\inetpub\wwwroot-storefront\CatalogManager
include name=**\*.* /
/fileset
/component
component name=D_WebServices feature=StorefrontProject
directory=D:\inetpub\wwwroot-storefront\WebServices
