[nant-dev] ResourceUtils
Hi Ian,
I think it would be preferable to have a common
resource assembly (e.g. NAnt.Resources.dll).
Letting an assembly access resources of another
assembly and viceversa is not that elegant. Moreover,
it would be difficult to maintain messages consistently.
There are also performance issues; actually, the code
for getting a localized string is as following:
public static string GetString(string name, CultureInfo culture)
{
if (resourceManager == null) {
lock (typeof(ResourceUtils)) {
if (resourceManager == null) {
Assembly assembly = Assembly.GetCallingAssembly();
resourceManager = new ResourceManager(
assembly.GetName().Name, assembly);
}
}
}
return resourceManager.GetString(name, culture);
}
In the code above, the lock takes place only once (the first
time a string is retrieved), assuring good performance.
Adding the functionality to register additional assemblies,
the lock would take place always as demonstrated in the following
code chunk:
static ResourceUtils()
{
resourceManagerDictionary = new ResourceManagerDictionary();
}
public static void RegisterAssembly(Assembly assembly)
{
lock (resourceManagerDictionary) {
resourceManagerDictionary.Add(assembly.GetName().Name,
new ResourceManager(assembly.GetName().Name, assembly))
}
}
public static string GetString(string name, CultureInfo culture)
{
string localizedString = null;
ResourceManager resourceManager = null;
lock (resourceManagerDictionary) {
foreach (DictionaryEntry entry in resourceManagerDictionary) {
resourceManager = entry.Value as ResourceManager;
localizedString = resourceManager.GetString(name, culture);
if (localizedString != null) {
break;
}
}
}
return localizedString;
}
The methods RegisterAssembly() and GetString() must be kept
synchronized...
What do you think about?
Giuseppe Greco
Software Architect
Banca del Gottardo
via Trevano 2A
6901 Lugano
Swizterland
Phone: +41 91 808 16 79
Fax: +41 91 808 24 00
Web: www.gottardo.com
-- DISCLAIMER --
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender
by return e-mail and delete this message from your system.Any unauthorised
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change.
Banca del Gottardo (including its group companies) shall not be liable for
the improper or incomplete transmission of the information contained in this
communication nor for any delay in its receipt or damage to your system.
Under no circumstances this message can be considered as a written acceptance
or confirmation of an instruction/order given to Banca del Gottardo.
Instructions and orders cannot be accepted or confirmed via e-mail.
Banca del Gottardo (or its group companies) does not guarantee that the
integrity
of this communication has been maintained nor that this communication is free of
viruses, interceptions or interference.
-
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1143958 ] VC++ project: /DEF without an argument
Bugs item #1143958, was opened at 2005-02-18 18:50 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1143958group_id=31650 Category: None Group: 0.85 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Jentsch (jentschi) Assigned to: Nobody/Anonymous (nobody) Summary: VC++ project: /DEF without an argument Initial Comment: I've build a VC++ project with the solution task and have the following problem: The project needs no moduldefinition and have no moduldefinition definied. But in the linker call a /DEF- option with no argument is inserted. This creates the fatal error LNK1146. [link] Starting 'link (@C:\DOKUME~1\JE9B86~1.GEF\L OKALE~ \Temp\tmp4908.tmp /IMPLIB:O:\devsrc\develop\dotnetGef\Shared\Interop\Mdl\mdlinteropengine.lib /DLL /INCRE MENTAL:NO /DEF: /MACHINE:X86 /FORCE)' in 'O:\devsrc\develop\dotnet\Gef\Shared\Interop\Mdl' [link] LINK : fatal error LNK1146: Kein Argument mit Option '/DEF:' angegeben -- Comment By: Gert Driesen (drieseng) Date: 2005-02-21 09:24 Message: Logged In: YES user_id=707851 Can you attach a small repro to this bug report, or send it to me by email ([EMAIL PROTECTED]) ? thx ! -- Comment By: Matthias Jentsch (jentschi) Date: 2005-02-21 09:04 Message: Logged In: YES user_id=682106 I'm using 0.85 RC2. -- Comment By: Gert Driesen (drieseng) Date: 2005-02-19 09:12 Message: Logged In: YES user_id=707851 Matthias, I was not able to reproduce this issue. What version of NAnt are you using ? 0.85 RC1 or RC2, or a nightly build ? Can you attach a small repro to this bug report ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1143958group_id=31650 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1143958 ] VC++ project: /DEF without an argument
Bugs item #1143958, was opened at 2005-02-18 18:50 Message generated for change (Comment added) made by jentschi You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1143958group_id=31650 Category: None Group: 0.85 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Jentsch (jentschi) Assigned to: Nobody/Anonymous (nobody) Summary: VC++ project: /DEF without an argument Initial Comment: I've build a VC++ project with the solution task and have the following problem: The project needs no moduldefinition and have no moduldefinition definied. But in the linker call a /DEF- option with no argument is inserted. This creates the fatal error LNK1146. [link] Starting 'link (@C:\DOKUME~1\JE9B86~1.GEF\L OKALE~ \Temp\tmp4908.tmp /IMPLIB:O:\devsrc\develop\dotnetGef\Shared\Interop\Mdl\mdlinteropengine.lib /DLL /INCRE MENTAL:NO /DEF: /MACHINE:X86 /FORCE)' in 'O:\devsrc\develop\dotnet\Gef\Shared\Interop\Mdl' [link] LINK : fatal error LNK1146: Kein Argument mit Option '/DEF:' angegeben -- Comment By: Matthias Jentsch (jentschi) Date: 2005-02-21 09:37 Message: Logged In: YES user_id=682106 The attached file nant1143958.zip contains a small VC++ project and a nant buildscript to reproduce this issue -- Comment By: Gert Driesen (drieseng) Date: 2005-02-21 09:24 Message: Logged In: YES user_id=707851 Can you attach a small repro to this bug report, or send it to me by email ([EMAIL PROTECTED]) ? thx ! -- Comment By: Matthias Jentsch (jentschi) Date: 2005-02-21 09:04 Message: Logged In: YES user_id=682106 I'm using 0.85 RC2. -- Comment By: Gert Driesen (drieseng) Date: 2005-02-19 09:12 Message: Logged In: YES user_id=707851 Matthias, I was not able to reproduce this issue. What version of NAnt are you using ? 0.85 RC1 or RC2, or a nightly build ? Can you attach a small repro to this bug report ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1143958group_id=31650 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] ResourceUtils
Greco Giuseppe wrote:
There are also performance issues; actually, the code
for getting a localized string is as following:
public static string GetString(string name, CultureInfo culture)
{
if (resourceManager == null) {
lock (typeof(ResourceUtils)) {
if (resourceManager == null) {
Assembly assembly = Assembly.GetCallingAssembly();
resourceManager = new ResourceManager(
assembly.GetName().Name, assembly);
}
}
}
return resourceManager.GetString(name, culture);
}
In the code above, the lock takes place only once (the first
time a string is retrieved), assuring good performance.
In the code above, there are unfortunately also correctness issues.
Ref:
http://weblogs.asp.net/oldnewthing/archive/2004/05/28/143769.aspx
http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf
The article on this page seems to imply that DCL is fixed in .Net, but
they still recommend using simple static initialisation.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/singletondespatt.asp
Also, I very much doubt that DCL is fixed in .Net... any virtual machine
with a memory model that would allow DCL to work without explicit
volatility would be unlikely to be performant in multithreaded
situations in which volatility were not required.
It's possible that DCL with an explicitly volatile member will work in
.Net, but I'm not familiar enough with .Net's memory model to know if
this is actually the case.
Adding the functionality to register additional assemblies,
the lock would take place always as demonstrated in the following
code chunk:
static ResourceUtils()
{
resourceManagerDictionary = new ResourceManagerDictionary();
}
public static void RegisterAssembly(Assembly assembly)
{
lock (resourceManagerDictionary) {
resourceManagerDictionary.Add(assembly.GetName().Name,
new ResourceManager(assembly.GetName().Name, assembly))
}
}
public static string GetString(string name, CultureInfo culture)
{
string localizedString = null;
ResourceManager resourceManager = null;
lock (resourceManagerDictionary) {
foreach (DictionaryEntry entry in resourceManagerDictionary) {
resourceManager = entry.Value as ResourceManager;
localizedString = resourceManager.GetString(name, culture);
if (localizedString != null) {
break;
}
}
}
return localizedString;
}
The methods RegisterAssembly() and GetString() must be kept
synchronized...
What do you think about?
Why doesn't GetString in this section restrict itself to the
ResourceManager for the calling assembly?
On an unrelated note, is there any reason you use a static initialiser
block instead of inline initialisation of your static member?
Regards,
-- Troy
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1116862 ] Different projects with same guid in a solution fail
Bugs item #1116862, was opened at 2005-02-05 15:19 Message generated for change (Comment added) made by ahildyard You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1116862group_id=31650 Category: Tasks Group: 0.85 Status: Open Resolution: None Priority: 5 Submitted By: Manu (manudea) Assigned to: Nobody/Anonymous (nobody) Summary: Different projects with same guid in a solution fail Initial Comment: Apply to nant 85 and 84 (maybe others) If you have 2 projects with same guid in a visual studio solution only the latter one is built. The first one is ignored. I think this is a Nant bug because VStudio builds just fine, so Nant should, IMHO, build in the same way as Vstudio does. Assuming that guid uniqueness exists in Vs solution it seems a wrong assumpton. If it would VS would complaint about this an do not build. -- Comment By: Alex Hildyard (ahildyard) Date: 2005-02-21 15:05 Message: Logged In: YES user_id=1114643 I actually think NAnt's behaviour is more correct than Visual Studio. Assuming that GUIDs are supposed to provide a mapping between project files and the project references within a solution file, I regard Visual Studio as defective because it will often continue to build solutions perfectly happily even when the two GUIDs don't match. This is clearly a recipe for disaster, since at some point Visual Studio's often inspired guesswork matching projects to solutions is going to be wrong. However, I agree that NAnt's behaviour isn't perfect. I would like to see NAnt throw an error if it finds duplicate GUIDs; I agree that silently building one of the projects and ignoring the other isn't the best behaviour. But I don't think reproducing Visual Studio's behaviour is the way to go. Just my tuppenceworth. Regards, Alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1116862group_id=31650 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1145670 ] Solution Circular Reference Error
Bugs item #1145670, was opened at 2005-02-21 13:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1145670group_id=31650 Category: Tasks Group: 0.85 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Voigt (jeffvoigt) Assigned to: Nobody/Anonymous (nobody) Summary: Solution Circular Reference Error Initial Comment: In regards to the Solution Task: When the solution file has two projects that reference each other, a StackOverflowException is thrown. This results in a JIT Debugging error (0x800405a6) to appear in the automated build process, and the log file will only contain the message fatal stack overflow. With the -debug+ flag on when running the build file, you will see Loading referenced project... messages alternating between the two circular referenced projects. This will continue until a stack overflow occurs. (See attached file) It is valid for two projects to reference each other. The Visual Studio IDE handles this gracefully, it would be nice if nant could too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1145670group_id=31650 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
