Okay, as a code modder for TS3, my first and foremost concern is the ability to modify the MSIL assemblies inside the game and be able to create new MSIL assemblies for objects.

I have been checking out the MSIL files for The Sims 3: World Adventures Expansion Pack and this is what I've found so far:

Gameplay.package:
--Sims3GameplayObjects.dll
--Sims3GameplaySystems.dll
--TestGameplay.dll
--UI.dll

Scripts.package:
--Automation.dll
--ScriptCore.dll
--SimIFace.dll
--Sims3Metadata.dll
--TestObjects.dll

simcore.package:
--mscorlib.dll
--System.dll
--System.Xml.dll

All of these assemblies were able to be successfully extracted from their respective packages via the latest version of S3PE and successfully loaded into Reflector afterwards.

It would have been good if the maxoids had decided to split some of these assemblies up into multiple ones to make core modding easier, but alas, the Highlander Rule still applies.

However, at first glance, there appear to only minor differences between the WA assemblies and their base game counterparts, such as Sims3GameplayObjects have additional TombObjects and TombObjects.AdventureRewards namespaces.

None of the already existing classes appear to have changed names.
This is definitely good news for core modders, as it will be easy to do a code difference analysis and create a WA compatible version of the replacement assembly.

From the looks of it, much of TS3:WA still depends on key base game files, particularly the FullBuild# packages.

More planned analysis:

--Analyzing the Resource.cfg files in the TS3:WA directory to begin planning on how to adapt Rick's wrapper to TS3:WA.

--Analyzing the differences between the assemblies to see how Reflection could be used to allow for universal versions of atomic (non-core) mods, such as my Chaos Mod Painting.

I've been looking at this, after I attempted to patch AwesomeMod to 1.66, and the result was somewhat of a disaster area. At the moment I am writing a new tool specifically for creating such patches, because GNU diff/patch has generated an unacceptably high reject rate this time around for some reason. As a side effect, misusing the tool will likely be able to merge core mods by rules similar to BHAV-merging of TS2.

That is quite interesting, Pescado. I'll have to look into the tool myself.

However, since my primary goal is creating non-core mods, I need to find out how I can distinguish between the base game assemblies and their WA counterparts to create a universal versions of non-core mods.

In terms of the Resource.cfg files, I only found two in the WA directories and their coding appears to be similar to their counterparts in the same locations in the base game directories.

Since there is obviously dependency on base game files, the exe must go back and read the Resource.cfg files in base game and previous expansion pack directories, which includes any additional third party Resource.cfg files that point to mod containing directories.
This is reinforced by the fact that one of the news announcements on SnootySims stated that third party custom content still loaded in WA.

The only question is whether or not Rick's d3dx9_31.dll wrapper would need to moved/copied to the new directory and modified in any way to allow custom MSIL assemblies to be loaded by the expansion pack.
I can't even speculate on that since I'm not clear on how the wrapper works.
The first thing I can do is load up the game and see if my painting still has its pie menu. Odds are it probably won't.

You just stick the dll in the same place as the executable, whereever it is. As for creating "universal" versions, as long as you're not referencing anything non-base, you're fine. If you DO reference something nonbase, I suspect the game may lock up before it even gets to that point, although you could sniff for the non-base material in reflection easily enough.

Sniffing out the non-base material with Reflection is easy enough to do, along with creating booleans that stop code from calling non-base functions, properties, and other things.

However, what about inheritance? What exactly happens in a program when you inherit from a class that doesn't exist or override a function that doesn't exist?
I mean, normally the IDE and compiler won't let you do that, but you can sneak around that by swapping out the referenced assembly with the older one that doesn't have the classes or functions.
What happens then? Is an error thrown upon static instantiation of the classes or does the program basically freeze up?
If it's the former, how does one catch and handle errors thrown by the static constructor of a class?

Try it and see? If you do it and it crashes, you'll have the answer there. I know if you reference an assembly that doesn't exist, the game will instantly hang before it even gets to the part where it tries to do anything.