>
>
> ...
>
>
>
>
>
> will work just fine.
>
Just a question: does the element automatically
embed the defalut resources into the assembly, or is the
element still necessary?
j3d.
-- DISCLAIMER ---
Ian MacLean wrote:
Ian MacLean wrote:
output="${build.dir}/${package.name}/lib/${culture}/${assembly}.resource
s.dll"
culture="${culture}">
...
value="-res:${build.dir}/${package.name}/lib/${default.resources}" />
we can use
Ian,
I'm at work too... so I cannot start right now...
j3d.
> -Original Message-
> From: Ian MacLean [mailto:[EMAIL PROTECTED]
> Sent: mercoledì, 16 febbraio 2005 08:40
> To: Greco Giuseppe
> Cc: nant-developers@lists.sourceforge.net
> Subject: Re: [nant-dev] L16N
>
>
>
> >The first
Ian MacLean wrote:
output="${build.dir}/${package.name}/lib/${culture}/${assembly}.resource
s.dll"
culture="${culture}">
...
value="-res:${build.dir}/${package.name}/lib/${default.resources}" />
we can use the child element for
The first step would be to create the resource files
(NAnt.Core.en-US.resx,
NAnt.DotNet.Task.en-US.resx, etc.),
we can just start with NAnt.Core.resx for the default ( US english )
language.
then replace hardcoded strings with
RM.GetString("Message_Id") - or whatever name you want, and finally a
Greco Giuseppe wrote:
I figured that one out :). We could probably call it
NAnt.Core.ResourceUtils or somthing like that.
That's up to you... but such a name is a little bit too long and
uncomfortable to be used often...
you think ? Show me some classes in the core framework that have 2
l
Ian,
> >You're right... attached to this email you'll find a better
> version of
> >RM.cs (RM stands for [R]esource[M]anager).
> >
> >
> >
> I figured that one out :). We could probably call it
> NAnt.Core.ResourceUtils or somthing like that.
That's up to you... but such a name is a little b
Perhaps we should explore a new mechanism for extension libraries in
NAnt, with inspiration taken from the Java jre/lib/ext idea...
4) Install NAntContrib to a different folder, and add an xml
descriptor/locator in NAnt/bin/ext which describes the library.
NAnt could scan the bin/ext folder for
I agree completely that installing on top of an existing NAnt installtion
would be quite rude :-). Maybe a "buyer beware" clause ought to apply. I
can't see how one can reasonably detect the presence of a NAnt installation
short of scanning all disks for NAnt.exe!
-Original Message-
From:
>From: [EMAIL PROTECTED]
>>Option 4 looks like an elegant (but long term) solution. How about a
>another
>>radical proposal:
If there's interest, I might be able to put together a
proof-of-concept this weekend.
>>The NAntContrib installer also installs a suitable version of NAnt
>>PROS: One inst
Greco Giuseppe wrote:
Ian,
looks ok - but why not get AssemblyName dynamically using :
Assembly.GetCallingAssembly() ?
then you only need to define the RM class once in NAnt.Core.
You're right... attached to this email you'll find a better
version of RM.cs (RM stands for [R]esource[M]anage
John Cole wrote:
There was a discussion on this topic a few months ago. The main point of
contention was installing NAnt/NAntContrib to the same directory or not and
whether or not to include NAntContrib at all in the installer.
My feelings remain the same. Use the MSI target as is. It works gre
My humble 2c worth ...
Option 4 looks like an elegant (but long term) solution. How about a another
radical proposal:
The NAntContrib installer also installs a suitable version of NAnt
PROS: One install installs both. Environment vars, paths all fixed up
correctly. Suitable versions of NAnt/Con
Swoogan wrote:
John Cole wrote:
There was a discussion on this topic a few months ago. The main point of
contention was installing NAnt/NAntContrib to the same directory or
not and
whether or not to include NAntContrib at all in the installer.
I was warring with the same dilema as far as NAnt/NAn
John Cole wrote:
There was a discussion on this topic a few months ago. The main point of
contention was installing NAnt/NAntContrib to the same directory or not and
whether or not to include NAntContrib at all in the installer.
My feelings remain the same. Use the MSI target as is. It works gre
There was a discussion on this topic a few months ago. The main point of
contention was installing NAnt/NAntContrib to the same directory or not and
whether or not to include NAntContrib at all in the installer.
My feelings remain the same. Use the MSI target as is. It works great, its
ready to
I agree that a win32 install would be a nice addition to NAnt. I
think it could get some people using NAnt that would otherwise shy
away from it...
The install script in NAntContrib is functional, to the best of my
knowledge. It just hasn't been used to generate official installs.
I would say t
Ian,
> looks ok - but why not get AssemblyName dynamically using :
> Assembly.GetCallingAssembly() ?
>
> then you only need to define the RM class once in NAnt.Core.
You're right... attached to this email you'll find a better
version of RM.cs (RM stands for [R]esource[M]anager).
Let me know if
Hi Martin,
I don't mind whether my code is in an exe or a dll - I would have needed
a wrapper for NAnt if it was an exe that's why I chose the dll.
I also didn't want to replace xsd.exe which has some extra features
MSDatasetGenerator (and my code) doesn't have, but if you've got a good
idea, ju
Ian,
> looks ok - but why not get AssemblyName dynamically using :
> Assembly.GetCallingAssembly() ?
>
> then you only need to define the RM class once in NAnt.Core.
>
It depends if you plan to create separate resource files for the
different NAnt assemblies. Furthermore, it depends also if yo
Oh - thats new info for me - thanks for clarification.
Still - shoudn't be better you write your code into .exe (like myxsd.exe)
and use existing task to call it? That way we could use whatever
replacement for xsd.exe we want (I'm just writing mine own)
btw: does current handle projects with M
Ian,
> sounds like a good idea. Why don't you log a bug for it ?
Done.
j3d.
> >
> >
> >-- DISCLAIMER
> >--
> >This message (including any attachments) is confidential and may be
> >privileged. If you have received it by mistake ple
Bugs item #1123001, was opened at 2005-02-15 10:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1123001&group_id=31650
Category: Core
Group: cvs
Status: Open
Resolution: None
Greco Giuseppe wrote:
Mono source code does not contain documentation comments; XML stubs
are generated via reflection with assembler.exe/updater.exe. Miguel
told me that they want to keep user documentation separated from
source code, meaning the /doc feature of the C# compiler is useless...
Hi Ian,
> looks like the xmldoc attribute you mention in a later email
> is the way
> to get around this. We would invoke ndoc once for each
> translated language.
Exactly...
> although we should be able to knock up a script to generate
> stubs based
> on the original english doc.
>
Of co
25 matches
Mail list logo
