Singleton (key/object dictionary) variable troubles
-
I'm trying to create a pluggable-type of ASP .Net tool to allow for images to be rendered through just one .aspx file, but through any number of assemblies that arent particularly bound... they just have to have a class that derives from a specific interface that allows drawing to an output stream. To me it seems easier to just have one .aspx file and use query strings to determine which class to use and have image creation data in there as well. I've tryed to use singletons, the cache, and the application for key/object storage. The keys are the strings used in the query strings to determine which type of class to use and the objects are instances of the classes [which I see mainly as just holder's of the drawing function, though perhaps class data might be necessary... but thats besides the point] Now for the problem... with all the methods I've tried various methods to get the keys and objects loaded... Singleton: 1. Load up on singleton class instantiation through reflection. [Also tried simply getting type-name strings to use Activator.Create(...)] 2. Use the Global.asax application start event to register all the objects directly (not quite as pluggable, but that could be patched by loading a custom data file and working with that) Cache & Application: 1. Use the Global.asax application/session start events to register the objects. For ALL of these I see that the place of instantiation/reflection/etc work in getting the data into the sorted list or key/object pair. However... once my application asks for the data, it finds the key... but the object passed is ALWAYS 'undefined value'... even with the type-name string. This I find interesting in 3 ways. a) The key was found... so the key "survived" somehow. b) The Value list browsed via the visual studio debugger does in fact have the correct value. c) Upon passing out to where its needed (the "ImageDraw.aspx.cs") the value is immediately 'undefined', to both the VS debugger and to attempts to call functions on it. Any clue as to why this happens..... this situation puts a HUGE damper on my plan to create nice pluggable systems. [a nice simple image drawer tool, ... web page 'units/blocks' loaded from database instructions.. etc] Oh yes.. if you wish to talk to me to discuss [if you think it'd be more productive initially than forum.. though itd be good to post up results here] AIM: Metalx1784 MSN/Windows Msgr: metalx15@hotmail.com email: metx84 @ comcast . net [get rid of the spaces... anti-span attempt]
-
I'm trying to create a pluggable-type of ASP .Net tool to allow for images to be rendered through just one .aspx file, but through any number of assemblies that arent particularly bound... they just have to have a class that derives from a specific interface that allows drawing to an output stream. To me it seems easier to just have one .aspx file and use query strings to determine which class to use and have image creation data in there as well. I've tryed to use singletons, the cache, and the application for key/object storage. The keys are the strings used in the query strings to determine which type of class to use and the objects are instances of the classes [which I see mainly as just holder's of the drawing function, though perhaps class data might be necessary... but thats besides the point] Now for the problem... with all the methods I've tried various methods to get the keys and objects loaded... Singleton: 1. Load up on singleton class instantiation through reflection. [Also tried simply getting type-name strings to use Activator.Create(...)] 2. Use the Global.asax application start event to register all the objects directly (not quite as pluggable, but that could be patched by loading a custom data file and working with that) Cache & Application: 1. Use the Global.asax application/session start events to register the objects. For ALL of these I see that the place of instantiation/reflection/etc work in getting the data into the sorted list or key/object pair. However... once my application asks for the data, it finds the key... but the object passed is ALWAYS 'undefined value'... even with the type-name string. This I find interesting in 3 ways. a) The key was found... so the key "survived" somehow. b) The Value list browsed via the visual studio debugger does in fact have the correct value. c) Upon passing out to where its needed (the "ImageDraw.aspx.cs") the value is immediately 'undefined', to both the VS debugger and to attempts to call functions on it. Any clue as to why this happens..... this situation puts a HUGE damper on my plan to create nice pluggable systems. [a nice simple image drawer tool, ... web page 'units/blocks' loaded from database instructions.. etc] Oh yes.. if you wish to talk to me to discuss [if you think it'd be more productive initially than forum.. though itd be good to post up results here] AIM: Metalx1784 MSN/Windows Msgr: metalx15@hotmail.com email: metx84 @ comcast . net [get rid of the spaces... anti-span attempt]
Well i certainly feel foolish.... I decided to look at my implementation again to see if there was a spoof.... turns out there was... the key I was using wasnt the key that matched with the object... so it returned null since it didnt have it... though I thought the indexer of SortedList was supposed to throw when the value didnt exist. Oh well.... back to working on the actual project now rather than debugging this issue, lol. Hmm.. does anyone have a good suggestion for which to use to store these interface implementation instances. I am using a singleton right now... but I'm using a single processor system and accessing it singly [no stress tests at all .. at least yet]. So... would Application, Cache, or the Singleton work best? I'd like the instance to be available indefinitely, perhaps adding new ones when a new one is available, or removing them when the dll is removed [and the config changed]. The removal however would be more difficult and would require a reload of the entire application due to the wonderful AppDomain unloading but no Assembly unloading [I really hope they add that ability in the next versions of .NET ... I'd like to have a good, simple plugin system that allowed removal without total unloads or using cross-AppDomain calls (I think that uses a form of remoting.. right?)]