bc-programming

HAHA! How's that for a clever title? Oh... well... ahem... nevermind. As a avid user of my own INIFile class, which I first write about- at least it's C# implementation- in my parsing INI files posting, I am always looking for ways to improve it's usage make it more "accessible". Recently, I have been tasked (by way of my new title of "freelance consultant") with creating several LOB (Line of Business) Type applications. Applications, naturally, have a tendency to lend their implementations to the creation and reading of settings. Being something of a fan of the simplicity of INI Files, I chose to use my INIFile class in the application. It works well, however, I have noticed that I have a lot of duplicate code. More specifically, I typically have to implement a "wrapper" class, which manages configuration information and reads/writes values to and from the INIFile as its own properties are accessed. For example: public bool PopulateUserOrderDropdown { get { bool tparse; if(bool.TryParse(OurINI["Admin.Settings"]["PopulateUserOrderDropDown","false"].Value,out tparse) return tparse; return false; } set { OurINI["Admin.Settings"]["PopulateUserOrderDropDown"].Value;} } Nothing too dreadful, but imagine having nearly the exact same thing repeated a number of times! The code is repeated and as Larry Wall says, one of the traits of a good programmer is sloth. I don't like having to write this same code over and over again! The INIFile is supposed to make it easy! The trouble here stems from the fact that the INIFile values are only strings; and typically, many settings are represented in the application itself as integers and booleans, dates, and so forth. My first attempt to mitigate the clutter was a static method, which I called xParse: public static class boolEx { public static bool xParse(String Value, bool Default) { bool parseresult; if(bool.TryParse(Value,out parseresult)) return parseresult; else return Default; } } relatively straightforward- basically it's a shell of what I had repeated over and over again. This mitigated the issue somewhat, so my properties in the wrapper looked like this: public bool PopulateUserOrderDropdown { get { return boolEx.xParse(OurINI["Admin.Settings"]["PopulateUserOrderDropDown", "false"].Value); } set { OurINI["Admin.Settings"]["PopulateUserOrderDropDown"].Value;} } much more managable, but still, could we not make this more concise? My first thought, was that perhaps I could eliminate the necessity of having the wrapper at all; I recalled two interfaces from my old COM programming days, specifically, IDispatch and IDispatchEx. Surely, I could do something similar? Unfortunately, the interfaces are for COM, and C# doesn't have dynamics until Version 4. So, I fired up Visual Studio 2010 express to see if I couldn't add the dynamic language constructs to the INIFile class; additionally, since I still need to work with .NET 3.5, I'll add the new code as a conditional compilation. The first step was deciding exactly what I wanted to happen. Imagine code like this: INIFile useINI = new INIFile("settings.ini"); String ConnectionString = (String)useINI.General.ConnectionString; The holy grail of the INIFile simplicity! Naturally, the .NET framework does provide the facility with which to add this functionality, as part of the System.Dynamic namespace. The first step was deciding on the method by which to conditional compile. Since projects copy the source of a file to your project folder when you add them, it seemed reasonable to simply add it as a #define right inside the INIFile class itself. #define CS4 And now, I just need to enclose all my new happy stuff in a conditional directive, and I'll get the best of both worlds- C# 4.0 consumers who keep the #define will be able to use the suave new feature, and older consumers will still be able to work without ripping apart the classes. The code to add this was surprisingly simple; as it stands now the longest method (An implementation of TryDeleteMember, which is never called from C#/VB.NET consumers, so is excessive for my usage). First, obviously we enclose the import statement in the conditional compile; the class headers are conditionally compiled as well, only deriving from DynamicObject with CS4 set. The core of the new functionality is in the overrides to the Dynamic Object's TryGetMember. For the INISection: public override bool TryGetMember(GetMemberBinder binder,out object result) { result = this[binder.Name]; return true; } And for the INIFile... public override bool TryGetMember(GetMemberBinder binder,out object result) { result = this[binder.Name]; return true; } Exactly the same, in fact. This works because of the indexer I added; the indexer will add the item if it doesn't exist and return the new value, so even if the member name doesn't exist, the INIFile will simply have that section added. That's for the retrieval of erements; to allow the assignment to them in the same fashion, we need to override TrySetMember(). In my case, this was a bit more involved, for flexibility purposes. For example, code like INIFile.MainSection="hello" should work, and change the name of the section. And why allow things like assignments from a Dictionary<String, String>, or maybe even a list (assigning a numbered id to set values)? And of course allow setting the Value directly, which will likely use the indexer much as I did for the TryGet... Implementations. public override bool TrySetMember(SetMemberBinder binder, object value) { //if it is a dataitem, set it directly. if (value is INIDataItem) { this[binder.Name] = (INIDataItem)value; return true; } else if (value is Tuple<, Object>) { Tuple<, Object> theTuple = (Tuple<, Object>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = theTuple.Item1; getitem.Value = theTuple.Item2.ToString(); return true; } else if (value is Tuple<, String>) { Tuple<, Object> theTuple = (Tuple<, Object>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = theTuple.Item1; getitem.Value = theTuple.Item2.ToString(); return true; } else if (value is KeyValuePair<, Object>) { //Allow a KeyValuePair<,Object> to be passed to set Name and Value. KeyValuePair<, Object> castedval = (KeyValuePair<, Object>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = castedval.Key; getitem.Value = castedval.Value.ToString(); return true; } else if (value is KeyValuePair<, String>) { //Allow a KeyValuePair<,String> to be passed to set Name and Value. KeyValuePair<, String> castedval = (KeyValuePair<, String>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = castedval.Key; getitem.Value = castedval.Value; return true; } else { this[binder.Name].Value = value.ToString(); return true; } } setting the Value should be equally flexible; since we can, why not? for example, why not make the following "legal"? INIFile.Section.Value="newvalue"; INIFile.Section.Value=DateTime.Now; INIFile.Section.Value=Tuple.Create("NewName","Chicken"); INIFile.Section.Value=Tuple.Create("NewName",DateTime.Now); The first example sets the Value to a string, the second sets it to a DateTime that is silently casted to a String (using toString(), and the last two use the new C# 4.0 tuples, to set both the name of the value and the value simultaneously. A more elegant solution would be to add this code to the Indexer, and merely call the indexer with the name and the value and return true if no exception occurs and false otherwise. However, I'm reluctant to go that route since some of the types are C# 4 types (Tuples). public override bool TrySetMember(SetMemberBinder binder, object value) { if (value is String) { this[binder.Name].Name = (String)value; return true; } else if (value is List<INIItem>) { INISection getsection = this[binder.Name]; getsection.INIItems = (List<INIItem>)value; return true; } else { return false; } } So Now, I've got an INI File implementation that supports Dynamic invocation. Well, that's great... except that the application I first found it clumsy in is using .NET 3.5, so I can't use the dynamic features. Back at square one. In C# 2008/3, we might not be able to leverage the power of dynamics, but we do have generics and Extension methods at our disposal. a feasible alternative could be to add a extension method to the INIDataItem class that has a generic type parameter that it will attempt to convert it's string Value into. First, using ChangeType, second, it can try to invoke a static TryParse on the given Type to parse the "value" string. And if none of that works, it can return a passed in default. This is still more verbose than the dynamic solution, but it has two distinct advantages- first, it's type-safe, so you get all the intellisense goodness, and second, it's still shorter than the alternative. Here is the code, which can be found in the cINIFile.cs file attached to this posting as well. public static class INItemValueExtensions { //extensions for INIDataItem //normally, INIDataItem is a Name/Value Pair; More Specifically, because of the way INI files are, they are //naturally typeless. However, most configuration options are mapped to a different type by the application. //and I've found it to be a gigantic pain to have to write the same TryParse() handling code over and over. //so I added these handy extensions to the INIDataItem class, which provide some functions for setting. //I keep them out of the main code simply because that way it doesn't clutter it up. It's already cluttered enough as-is. /// <summary> /// Attempts to use Convert.ChangeType() to change the Value of this INIDataItem to the specified type parameter. /// If this fails, it will attempt to call a static "TryParse(String, out T)" method on the generic type parameter. /// If THAT fails, it will return the passed in DefaultValue parameter. /// </summary> /// <typeparam name="T">Parameter Type to retrieve and act on in Static context.</typeparam> /// <param name="dataitem">INIDataItem instance whose value is to be parsed to the given type.</param> /// <param name="DefaultValue">Default value to return</param> /// <returns>Result of the parse/Conversion, or the passed in DefaultValue</returns> public static T GetValue<T>(this INIDataItem dataitem, T DefaultValue) { //Generic method, attempts to call a static "TryParse" argument on the given class type, passing in the dataitem's value. try { return (T)Convert.ChangeType(dataitem.Value, typeof(T)); } catch (InvalidCastException ece) { //attempt to call TryParse. on the static class type. //TryParse(String, out T) Type usetype = typeof(T); T result = default(T); Object[] passparams = new object[] { dataitem.Value, result }; try { bool tpresult = (bool)usetype.InvokeMember("TryParse", BindingFlags.Static, null, null, passparams); if (tpresult) { //tryparse succeeded! return (T)passparams[1]; //second index was out parameter... } } catch (Exception xx) { //curses... return DefaultValue; } } return DefaultValue; } /// <summary> /// Logical inverse of the getValue routine... a bit faster to implement... /// </summary> /// <typeparam name="T"></typeparam> /// <param name="dataitem"></param> /// <param name="newvalue"></param> public static void setValue<T>(this INIDataItem dataitem, T newvalue) { dataitem.Value = newvalue.ToString(); } private static void GetTypeDefault<T>(out T result) { Type tt = typeof(T); //basic idea: call default, empty constructor using reflection. ConstructorInfo defaultconstructor = tt.GetConstructor(new Type[] { }); result = (T)defaultconstructor.Invoke(null); } } And there you have it, a bunch of awesome additions. INI files are often thought of as deprecated, but that's only the INIFile functions. This class was designed because working with the registry makes it difficult to test properly, and because JSON,YAML, and many other formats are excessively complicated. when you just need a few basic settings, all you need is the clean, simple format of a INI file. And now, with these additions, code for reading from those INI files is clean and simple as well! The Source- cINIFile.cs

HAHA! How’s that for a clever title?

Oh… well… ahem… nevermind.

As a avid user of my own INIFile class, which I first write about- at least it’s C# implementation- in my parsing INI files posting, I am always looking for ways to improve it’s usage make it more “accessible”.

Recently, I have been tasked (by way of my new title of “freelance consultant”) with creating several LOB (Line of Business) Type applications. Applications, naturally, have a tendency to lend their implementations to the creation and reading of settings. Being something of a fan of the simplicity of INI Files, I chose to use my INIFile class in the application. It works well, however, I have noticed that I have a lot of duplicate code. More specifically, I typically have to implement a “wrapper” class, which manages configuration information and reads/writes values to and from the INIFile as its own properties are accessed. For example:

Nothing too dreadful, but imagine having nearly the exact same thing repeated a number of times! The code is repeated and as Larry Wall says, one of the traits of a good programmer is sloth. I don’t like having to write this same code over and over again! The INIFile is supposed to make it easy!

The trouble here stems from the fact that the INIFile values are only strings; and typically, many settings are represented in the application itself as integers and booleans, dates, and so forth. My first attempt to mitigate the clutter was a static method, which I called xParse:

relatively straightforward- basically it’s a shell of what I had repeated over and over again. This mitigated the issue somewhat, so my properties in the wrapper looked like this:

much more managable, but still, could we not make this more concise? My first thought, was that perhaps I could eliminate the necessity of having the wrapper at all; I recalled two interfaces from my old COM programming days, specifically, IDispatch and IDispatchEx. Surely, I could do something similar?

Unfortunately, the interfaces are for COM, and C# doesn’t have dynamics until Version 4.

So, I fired up Visual Studio 2010 express to see if I couldn’t add the dynamic language constructs to the INIFile class; additionally, since I still need to work with .NET 3.5, I’ll add the new code as a conditional compilation.

The first step was deciding exactly what I wanted to happen. Imagine code like this:

The holy grail of the INIFile simplicity! Naturally, the .NET framework does provide the facility with which to add this functionality, as part of the System.Dynamic namespace.

The first step was deciding on the method by which to conditional compile. Since projects copy the source of a file to your project folder when you add them, it seemed reasonable to simply add it as a #define right inside the INIFile class itself.

#define CS4

And now, I just need to enclose all my new happy stuff in a conditional directive, and I’ll get the best of both worlds- C# 4.0 consumers who keep the #define will be able to use the suave new feature, and older consumers will still be able to work without ripping apart the classes. The code to add this was surprisingly simple; as it stands now the longest method (An implementation of TryDeleteMember, which is never called from C#/VB.NET consumers, so is excessive for my usage). First, obviously we enclose the import statement in the conditional compile; the class headers are conditionally compiled as well, only deriving from DynamicObject with CS4 set.

The core of the new functionality is in the overrides to the Dynamic Object’s TryGetMember.

For the INISection:

And for the INIFile…

Exactly the same, in fact. This works because of the indexer I added; the indexer will add the item if it doesn’t exist and return the new value, so even if the member name doesn’t exist, the INIFile will simply have that section added.

That’s for the retrieval of erements; to allow the assignment to them in the same fashion, we need to override TrySetMember(). In my case, this was a bit more involved, for flexibility purposes.

For example, code like INIFile.MainSection=”hello” should work, and change the name of the section. And why allow things like assignments from a Dictionary<String, String>, or maybe even a list (assigning a numbered id to set values)? And of course allow setting the Value directly, which will likely use the indexer much as I did for the TryGet… Implementations.

setting the Value should be equally flexible; since we can, why not?
for example, why not make the following “legal”?

The first example sets the Value to a string, the second sets it to a DateTime that is silently casted to a String (using toString(), and the last two use the new C# 4.0 tuples, to set both the name of the value and the value simultaneously.

A more elegant solution would be to add this code to the Indexer, and merely call the indexer with the name and the value and return true if no exception occurs and false otherwise. However, I’m reluctant to go that route since some of the types are C# 4 types (Tuples).

So Now, I’ve got an INI File implementation that supports Dynamic invocation. Well, that’s great… except that the application I first found it clumsy in is using .NET 3.5, so I can’t use the dynamic features. Back at square one.

In C# 2008/3, we might not be able to leverage the power of dynamics, but we do have generics and Extension methods at our disposal. a feasible alternative could be to add a extension method to the INIDataItem class that has a generic type parameter that it will attempt to convert it’s string Value into. First, using ChangeType, second, it can try to invoke a static TryParse on the given Type to parse the “value” string. And if none of that works, it can return a passed in default. This is still more verbose than the dynamic solution, but it has two distinct advantages- first, it’s type-safe, so you get all the intellisense goodness, and second, it’s still shorter than the alternative.

Here is the code, which can be found in the cINIFile.cs file attached to this posting as well.

And there you have it, a bunch of awesome additions. INI files are often thought of as deprecated, but that’s only the INIFile functions. This class was designed because working with the registry makes it difficult to test properly, and because JSON,YAML, and many other formats are excessively complicated. when you just need a few basic settings, all you need is the clean, simple format of a INI file. And now, with these additions, code for reading from those INI files is clean and simple as well!

The Source- cINIFile.cs

Most Computer users are familiar with the Sounds that Windows emits when you plug and unplug a USB thumb drive. It's a useful form of auditory feedback that the drive was in fact detected. However, I've found linux to be oddly tacit in this regard. So I set to work writing a python script that uses DBUS to monitor for new USB devices and will play a sound whenever a new Volume is attached. #!/usr/bin/python #by BC_Programming import dbus import gobject import time import subprocess print "BASeCamp 'USBSounds' Simple USB Volume notification sound." #playsound merely shells out to mplayer. I would have preferred an integrated solution but... meh. def playsound(soundfile): subprocess.call(["mplayer", "hardwareinsert.wav"], stdout=open('/dev/null', 'w'), stderr=open('/dev/null', 'w')) class DeviceAddedListener: def __init__(self): #get the system bus... self.bus = dbus.SystemBus() #get the manager self.hal_manager_obj = self.bus.get_object( 'org.freedesktop.Hal', '/org/freedesktop/Hal/Manager') #get the interface for the manager self.hal_manager = dbus.Interface(self.hal_manager_obj,'org.freedesktop.Hal.Manager') #connect to the appropriate signals. self.hal_manager.connect_to_signal('DeviceAdded', self._filteradd) self.hal_manager.connect_to_signal("DeviceRemoved",self._filterremove) #note: I couldn't get DeviceRemoval sounds to work since it doesn't let you #inspect whether the removed device is a volume via "QueryCapability"... since it's gone. def _filteradd(self, udi): device_obj = self.bus.get_object ('org.freedesktop.Hal', udi) device = dbus.Interface(device_obj, 'org.freedesktop.Hal.Device') #if it is a volume, call the do_add function... if device.QueryCapability("volume"): return self.do_add(device) def _filterremove(self,udi): try: #device_obj = self.bus.get_object('org.freedesktop.Hal',udi) #device = dbus.Interface(device_obj,'org.freedesktop.Hal.Device') #if device.QueryCapability("volume"): # return self.do_remove(device) except: return #unused.... def do_remove(self,volume): playsound("hardwareremove.wav") #displays some info about the added device to the console (maybe future changes can pop stuff like volume label, device file, size, etc into a Notification box?) def do_add(self, volume): device_file = volume.GetProperty("block.device") label = volume.GetProperty("volume.label") fstype = volume.GetProperty("volume.fstype") mounted = volume.GetProperty("volume.is_mounted") mount_point = volume.GetProperty("volume.mount_point") try: size = volume.GetProperty("volume.size") except: size = 0 print "New storage device detected:" print " device_file: %s" % device_file print " label: %s" % label print " fstype: %s" % fstype if mounted: print " mount_point: %s" % mount_point else: print " not mounted" print " size: %s (%.2fGB)" % (size, float(size) / 1024**3) #and play a sound. playsound("hardwareinsert.wav") #main loop... if __name__ == '__main__': from dbus.mainloop.glib import DBusGMainLoop DBusGMainLoop(set_as_default=True) loop = gobject.MainLoop() print "in __main__..." DeviceAddedListener() loop.run() As can be seen, it's a tad messy, and even rather hackish. For one thing, it uses DBUS, which to my understanding is deprecated. Unfortunately, the replacement I couldn't really get a clear answer on. From what I can gather, the proper method for now is libnotify and pynotify, but I couldn't get libnotify to compile and thus was not able to properly use pynotify, and I didn't want to have to force people to go through that sort of hell when they tried to use my script, so I stuck to DBUS. The only limitation I discovered is that on device removal, you can't really inspect what device was removed. At first I just figured, Just play the sound everytime and let the user figure it out, but for some reason that just assaulted me with constant device removal sounds. So I ended up commenting (and I think removing) that particular segment of code. Playing Sounds is unnecessarily difficult in Python, or more specifically, Linux. It's ridiculous. First I found a build in module for python, ossdevsound (or something to that effect), but attempts to use that failed because apparently it uses OSS, which apparently was replaced by ALSA for whatever reason. So I tried pygame, which errored out that I had no mixer device when I tried to initialize the mixer. So I decided to hell with it and just spawned a mplayer process, and redirected it's stdout to NULL to avoid the nasty business where it barfs all over the console. And amazingly, that seems to work fine for device insertions, which I decided I was content with. By default I use the Windows insertion and removal sound files. The removal sound isn't actually used but I kept it in the g-zipped tar because I wanted to. Personally I usually just launch this in a terminal and then tuck it away on another desktop. No doubt one can execute it as a daemon or something instead and get the functionality without the console window baggage to keep around, though. ThumbNotify.tar.gz

Most Computer users are familiar with the Sounds that Windows emits when you plug and unplug a USB thumb drive. It’s a useful form of auditory feedback that the drive was in fact detected. However, I’ve found linux to be oddly tacit in this regard. So I set to work writing a python script that uses DBUS to monitor for new USB devices and will play a sound whenever a new Volume is attached.

As can be seen, it’s a tad messy, and even rather hackish. For one thing, it uses DBUS, which to my understanding is deprecated. Unfortunately, the replacement I couldn’t really get a clear answer on. From what I can gather, the proper method for now is libnotify and pynotify, but I couldn’t get libnotify to compile and thus was not able to properly use pynotify, and I didn’t want to have to force people to go through that sort of hell when they tried to use my script, so I stuck to DBUS.

The only limitation I discovered is that on device removal, you can’t really inspect what device was removed. At first I just figured, Just play the sound everytime and let the user figure it out, but for some reason that just assaulted me with constant device removal sounds. So I ended up commenting (and I think removing) that particular segment of code.

Playing Sounds is unnecessarily difficult in Python, or more specifically, Linux. It’s ridiculous. First I found a build in module for python, ossdevsound (or something to that effect), but attempts to use that failed because apparently it uses OSS, which apparently was replaced by ALSA for whatever reason. So I tried pygame, which errored out that I had no mixer device when I tried to initialize the mixer. So I decided to hell with it and just spawned a mplayer process, and redirected it’s stdout to NULL to avoid the nasty business where it barfs all over the console. And amazingly, that seems to work fine for device insertions, which I decided I was content with.

By default I use the Windows insertion and removal sound files. The removal sound isn’t actually used but I kept it in the g-zipped tar because I wanted to. Personally I usually just launch this in a terminal and then tuck it away on another desktop. No doubt one can execute it as a daemon or something instead and get the functionality without the console window baggage to keep around, though.

ThumbNotify.tar.gz

It's a relatively trivial task, really easy to do with the command prompt and GNU wc: for /f "delims=" %P in ('dir /s /b *.cs') do wc -l "%P" >> D:\codewordcounts.txt I executed this within the desired directory (my BASeBlock source folder, if you must know) and the result was a file filled with numbers and files; I wrote a quick python script to parse that and add up the numbers that were at the start of each line, but then I figured, why not just write the whole think in python and forget about the rest of it, so I did. #!/usr/bin/python import sys import fnmatch import os def searchfolder(folder,filemask,excludemask): filelist=[] for root,subFolders,files in os.walk(folder): for file in files: buildpath=os.path.join(root,file) if os.path.isfile(buildpath): if fnmatch.fnmatch(buildpath,filemask): if not fnmatch.fnmatch(buildpath,excludemask): filelist.append(buildpath) return filelist def Countlines(filename): #counts the lines in filename. countit = open(filename) runner=0 for line in countit: runner=runner+1 return runner searchfor = sys.argv[1] searchin = sys.argv[2] excludethese = sys.argv[3] print "examining files matching " + searchfor + " in directory " + searchin + " excluding " + excludethese totalcount=0 for countthese in searchfolder(searchin,searchfor,excludethese): #print Countlines(countthese) totalcount = totalcount + Countlines(countthese) print "total line count:" + totalcount It's a rather basic script, and I don't even comment it as much as I ought to. I just wanted a quick tool to be able to count the lines of code in a given directory for a given source file type. Ideally, I'd allow for multiple types, but I didn't want to complicate the argument parsing code too much. The counting method is pretty barren, it just loops over every line and increments a counter. It seems to work relatively fast. It quickly gave me the result I wanted, which was that BASeBlock's .cs files comprise about 53K lines of code, excluding the .designer.cs files (thus the third argument). And now I have a nice reusable script to figure this out in a jiffy without too much thinking about shell syntax or what I need to pipe to wc and what arguments I need to pass wc and whatnot. plonked in a location on my windows machine with pathext set to allow execution of .py files directly using the ActivePython interpreter and putting it on my Linux machine and adding a symlink in /usr/bin to it makes it available to me on both machines.

It’s a relatively trivial task, really easy to do with the command prompt and GNU wc:

I executed this within the desired directory (my BASeBlock source folder, if you must know) and the result was a file filled with numbers and files; I wrote a quick python script to parse that and add up the numbers that were at the start of each line, but then I figured, why not just write the whole think in python and forget about the rest of it, so I did.

It’s a rather basic script, and I don’t even comment it as much as I ought to. I just wanted a quick tool to be able to count the lines of code in a given directory for a given source file type. Ideally, I’d allow for multiple types, but I didn’t want to complicate the argument parsing code too much. The counting method is pretty barren, it just loops over every line and increments a counter. It seems to work relatively fast. It quickly gave me the result I wanted, which was that BASeBlock’s .cs files comprise about 53K lines of code, excluding the .designer.cs files (thus the third argument). And now I have a nice reusable script to figure this out in a jiffy without too much thinking about shell syntax or what I need to pipe to wc and what arguments I need to pass wc and whatnot. plonked in a location on my windows machine with pathext set to allow execution of .py files directly using the ActivePython interpreter and putting it on my Linux machine and adding a symlink in /usr/bin to it makes it available to me on both machines.

So, as mentioned in the previous post, I added a "sort" of scriptability to BASeBlock. I made some tweaks, and refactored the code so it was a bit more abstracted; the original implementation was directly in the MultiTypeManager, but that didn't really have anything to do with it, so I tweaked some of the parameters to a few methods there, added a new class with the static routines required for the needed functionality, etc. I also made it so that a "BASeBlock Script Group file" (.bbsg extension) could be used to both compile a set of files into an assembly, as well as include various other assemblies as required. Future additions will probably include the ability for each assembly to define a sort of "main" method, which can be called when the assembly is initialized. However, once again, Serialization was the constant thorn in my side. I was able to mess about with a custom block written in a .cs script, and it even saved properly. But the game encountered an exception when I tried to open that LevelSet; I forget the specifics, something to the tune of "failed to find assembly"  type of error. What could I do?  SerializationBinder What this basically meant was I was going to have to learn even more about the Serialization structure of .NET. Specifically, SerializationBinder's. The concept was actually quite simple. You basically just derive a type from SerializationBinder, and use that as the .Binder property on a IFormatter class, overriding one method seems to be enough for the most part: &nbsp; Type BindToType(string assemblyName, string typeName) &nbsp; Simple! it gives you an assembly Name, a Type Name, and you simply return the appropriate type. The reason the default implementation wasn't working was certainly as a result of the assembly being loaded dynamically, since it wasn't [i]really[/i] being referenced by the BASeBlock assembly, so the default implementation didn't find the "plugin" class assembly or the appropriate type, so threw an exception. The trick here is not to enumerate the referenced assemblies, but rather to use all loaded assemblies in the current AppDomain. The general consensus with regards to using CodeDOM and compiling things like this is to compile them to their own AppDomain; however, since the assemblies were being kept "alive" for the duration of the application, that wasn't necessary, and in this case would have complicated things. Well, it would have complicated things more than they already were. The "AssemblyName" parameter, however, was more akin to the FullName property of the System.Reflection.Assembly; for example, BASeBlock's assembly would (for the current version) be passed in as "BASeBlock, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null". Since we are only interested in the actual name of the assembly, we can simply grab everything up to the first comma. Armed with the Assembly's base name, we can start enumerating all the loaded Assemblies and looking for a match: public override Type BindToType(string assemblyName, string typeName) { try { string BaseAssemblyName = assemblyName.Split(',')[0]; Assembly[] Assemblies = AppDomain.CurrentDomain.GetAssemblies(); foreach (Assembly loopassembly in Assemblies) { if (loopassembly.FullName.Split(',')[0].Equals(BaseAssemblyName,StringComparison.OrdinalIgnoreCase)) { return loopassembly.GetType(typeName); } } } catch (System.Exception exception) { throw exception; } return null; } Then, we compare the Assembly.FullName.Split(',')[0] (the text before the first comma) to the modified string, BaseAssemblyName that was changed in the same manner. I decided to go string insensitive for no reason; mostly because the assembly names for the scripts are formed from the filenames and I wouldn't want filename capitalization to prevent a script from serializing/deserializing properly. If we find a matching assembly, we return the result of a GetType() call to that assembly with the same typename passed in as a parameter to the method. The Formatter will than attempt to deserialize the data it has to that type as needed. There are a few issues with this- for one thing, it doesn't work with Generic types. At least, I assume it doesn't; I assume I would need some special code to get the appropriate Type for a generic type given type arguments. I'll cross that bridge when I come to it. Right now, I've not actually tested this extensively. My main concern would be to test that it can serialize in one session, and deserialize in another. This concern is based on the fact that the two assemblies would in that case be literally distinct- in that it would have been compiled on two occasions. Assuming the Binder is enough to convince the serializer it can deserialize something, there shouldn't be any issues. Once I decide to figure out how to add Generics support to this Binder, I'll definitely write about it here.

So, as mentioned in the previous post, I added a “sort” of scriptability to BASeBlock.

I made some tweaks, and refactored the code so it was a bit more abstracted; the original implementation was directly in the MultiTypeManager, but that didn’t really have anything to do with it, so I tweaked some of the parameters to a few methods there, added a new class with the static routines required for the needed functionality, etc. I also made it so that a “BASeBlock Script Group file” (.bbsg extension) could be used to both compile a set of files into an assembly, as well as include various other assemblies as required. Future additions will probably include the ability for each assembly to define a sort of “main” method, which can be called when the assembly is initialized.

However, once again, Serialization was the constant thorn in my side. I was able to mess about with a custom block written in a .cs script, and it even saved properly.

But the game encountered an exception when I tried to open that LevelSet; I forget the specifics, something to the tune of “failed to find assembly”  type of error. What could I do?

 SerializationBinder

What this basically meant was I was going to have to learn even more about the Serialization structure of .NET. Specifically, SerializationBinder’s. The concept was actually quite simple. You basically just derive a type from SerializationBinder, and use that as the .Binder property on a IFormatter class, overriding one method seems to be enough for the most part:

Simple! it gives you an assembly Name, a Type Name, and you simply return the appropriate type. The reason the default implementation wasn’t working was certainly as a result of the assembly being loaded dynamically, since it wasn’t [i]really[/i] being referenced by the BASeBlock assembly, so the default implementation didn’t find the “plugin” class assembly or the appropriate type, so threw an exception.

The trick here is not to enumerate the referenced assemblies, but rather to use all loaded assemblies in the current AppDomain. The general consensus with regards to using CodeDOM and compiling things like this is to compile them to their own AppDomain; however, since the assemblies were being kept “alive” for the duration of the application, that wasn’t necessary, and in this case would have complicated things. Well, it would have complicated things more than they already were.

The “AssemblyName” parameter, however, was more akin to the FullName property of the System.Reflection.Assembly; for example, BASeBlock’s assembly would (for the current version) be passed in as “BASeBlock, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null”. Since we are only interested in the actual name of the assembly, we can simply grab everything up to the first comma.

Armed with the Assembly’s base name, we can start enumerating all the loaded Assemblies and looking for a match:

Then, we compare the Assembly.FullName.Split(‘,’)[0] (the text before the first comma) to the modified string, BaseAssemblyName that was changed in the same manner. I decided to go string insensitive for no reason; mostly because the assembly names for the scripts are formed from the filenames and I wouldn’t want filename capitalization to prevent a script from serializing/deserializing properly. If we find a matching assembly, we return the result of a GetType() call to that assembly with the same typename passed in as a parameter to the method. The Formatter will than attempt to deserialize the data it has to that type as needed.

There are a few issues with this- for one thing, it doesn’t work with Generic types. At least, I assume it doesn’t; I assume I would need some special code to get the appropriate Type for a generic type given type arguments. I’ll cross that bridge when I come to it.

Right now, I’ve not actually tested this extensively. My main concern would be to test that it can serialize in one session, and deserialize in another. This concern is based on the fact that the two assemblies would in that case be literally distinct- in that it would have been compiled on two occasions. Assuming the Binder is enough to convince the serializer it can deserialize something, there shouldn’t be any issues. Once I decide to figure out how to add Generics support to this Binder, I’ll definitely write about it here.

For quite some time I've been wrestling with a mysterious issue. You see, I have several COM components. COM, is, to be usable from the various Script languages installed with windows. I encountered this some time ago when creating a small demonstration script file, something along the lines of the following, which simply showed a files size: Set BCFS = CreateObject("BCFile.BCFSObject") Set ffile = BCFS.GetFile(WScript.Arguments(1)) WScript.echo BCFS.FormatSize(ffile.Size) Very basic. However, upon running it, I was greeted with the helpful dialog shown in figure 22-1. [caption id="attachment_131" align="alignleft" width="490" caption="Fig 22-1: VBScript Error"][/caption] For some reason or another, the ActiveX Object simply couldn't be created (I gathered this after many long hours of research). My first "retry" was simple- I at first simply assumed that I had to run as administrator, so I started a command prompt as administrator, and ran it again. Same error. This was getting to be annoying. I tried a equal script in JScript/ECMAScript or whatever the hell it's called these days: BCFS = new ActiveXObject("BCFile.BCFSObject"); ffile = BCFS.GetFile(WScript.Arguments[1]); WScript.echo(BCFS.FormatSize(ffile.Size)); It failed as well. so it wasn't because of something I was doing wrong in the script. I then tried an alternative; I created a Visual Basic Project, and ran similar code. It was able to create and use the object with absolutely no difficulty. I was beginning to find this whole exercise at least as intriguing as it was frustrating. I decided to explore what happened with other operating Systems with VMWare. The script ran fine in Windows 2000 and Windows XP (assuming of course I had installed BCSearch or otherwise had BCFile.dll properly installed). However, it continued to fail. I went into a test frenzy. It failed on Windows 7 on both my laptop and desktop, worked in all my VMWare installations (including Vista) I was stymied. Then, I ran it on two copies of Windows XP I had on my laptop. Windows XP Pro worked fine. Windows XP x64 did not. So it was an architecture issue, I surmised. Going on that, I came to the realization that a 64-bit executable cannot instantiate a 32-bit COM object, at least, not an In-Process (DLL) COM object. This was likely the source of the error. I Ran a simple script with a msgbox() that would keep the Script runner running, and then opened Process Explorer. Not surprisingly, the WScript.exe Process was 64-bit, this was the cause of my problems. the fix? Run the WScript or CScript in %systemroot%\syswow64\ instead. I did so, and the script ran without incident.

For quite some time I’ve been wrestling with a mysterious issue.

You see, I have several COM components. COM, is, to be usable from the various Script languages installed with windows. I encountered this some time ago when creating a small demonstration script file, something along the lines of the following, which simply showed a files size:

Very basic.

However, upon running it, I was greeted with the helpful dialog shown in figure 22-1.

Fig 22-1: VBScript Error

For some reason or another, the ActiveX Object simply couldn’t be created (I gathered this after many long hours of research). My first “retry” was simple- I at first simply assumed that I had to run as administrator, so I started a command prompt as administrator, and ran it again.

Same error.

This was getting to be annoying. I tried a equal script in JScript/ECMAScript or whatever the hell it’s called these days:

It failed as well. so it wasn’t because of something I was doing wrong in the script. I then tried an alternative; I created a Visual Basic Project, and ran similar code.

It was able to create and use the object with absolutely no difficulty.

I was beginning to find this whole exercise at least as intriguing as it was frustrating. I decided to explore what happened with other operating Systems with VMWare. The script ran fine in Windows 2000 and Windows XP (assuming of course I had installed BCSearch or otherwise had BCFile.dll properly installed). However, it continued to fail. I went into a test frenzy. It failed on Windows 7 on both my laptop and desktop, worked in all my VMWare installations (including Vista) I was stymied.

Then, I ran it on two copies of Windows XP I had on my laptop. Windows XP Pro worked fine. Windows XP x64 did not.

So it was an architecture issue, I surmised. Going on that, I came to the realization that a 64-bit executable cannot instantiate a 32-bit COM object, at least, not an In-Process (DLL) COM object. This was likely the source of the error. I Ran a simple script with a msgbox() that would keep the Script runner running, and then opened Process Explorer.

Not surprisingly, the WScript.exe Process was 64-bit, this was the cause of my problems. the fix? Run the WScript or CScript in %systemroot%\syswow64\ instead. I did so, and the script ran without incident.