First of all, the name of the dll is not Drawing.dll, but it's System.Drawing.dll. Also, with this method (Type.GetType()), for extrnal types (not defined in mscorlib.dll) you need to specify the fully qualified name of the type, which includes full assembly (ll) name information, so you'd need something like:
Probably too much trouble doing it like that, so I think it's better to get first an Assembly object of the dll that contains the type, then do a simple oAssembly:GetType(), where you can specify the type simply by its name.
I will give it a go - both ways, so I can at least then explain 'stuff' in my eNotes, and publish some code that does work and produce results.
Have you any idea why there is such a change required ? Is it because there is no way they (MS) are going to change the core assemblies, but reserve the right etc. to change assemblies more on the 'fringe' of things ?
this will give you the complete name of the type that you need, together with the full assembly name.
But I think there's no point at all to go that route, I don't think anybody is ever using Type.GetType() this way. Normal way is to get an Assembly object (either by directly loading from disk with Assembly.LoadFrom() or LoadFile()), or get it through other means, for example Assembly.GetEntryAssembly():GetReferencedAssemblies() gives the referenced assemblies of your main app).
The problem with the first method you used, is that the type you ask for maybe declared in one of the thousands of .Net dlls that are included in every PC (unless it's one of the standard types, defined in mscorlib.dll). So in order to avoid loading and examining (after finding!) every single dll in the disk in order to find the type you are asking for, Type.GetType() requires to specify and describe completely the dll file where the type is located in, so it can load it at runtime and get the type defined in it. And still AFAIK it will not find types in dlls located just in some folder in the PC, but only if the dll is also registered in the GAC.
For this reason, I think using Type.GetType(string) is completely impractical and you need to use one of the more straightforward methods of loading the assembly manually first and then locate the type inside the assembly.
I will adjust my researching and the way I attack the problem, and the way I write the eNotes. This is not a topic that I have given much attention to over the years - hence I came at it in the wrong way / direction.