One of them is the Delphi Studio 2006. With the new machine that is relatively clean in terms of LUA conformance it is also a good opportunity to see how well D2006 behaves in LUA. On my previous machine, it seemed fine but I might have been less stringent with the conformance.
As required, D2006 was installed in an Administrator account. This is an interesting fact to remember. It is not in an Administrator console. I actually logged into the Administrator's account to install. The installation went pretty flawlessly.
After that I logged back into my normal account, which is an LUA, things got interesting. With ProcMon and ProcExp configured to monitor BDS.EXE, I was ready to fire up Delphi Studio and here are the problems encountered:
1) During the start up, bds tried to copy "<.Net 1.1 Framework SDK Dir>\bin\lc.exe to the "C:\Program Files\Borland\BDS\4.0\bin" as lc.dll. Of course this is futile as I am only a LUA.
I am just wondering why Borland would want to change Microsoft's License Compiler into a License DLL. Doesn't Borland know that it can late bind into LC.EXE just as easily as LC.DLL by virtue of the CLR assembly probing algorithm coupled with reflection? All you need to do is to specify the type name correctly. But perhaps Borland did an early binding in their lab. Not very elegant in my mind. Is it also ethical to rename a Microsoft executable?
Anyway, realizing BDS is trying to do the impossible, I gave it a helping hand so as to go past this hurdle.
2) Next that showed up on the radar screen was that BDS trying to change the value of this registration item:
HKCR\TypeLib\{F939BACD-3FD5-437A-833F-BA3535A45966}\a.0\0\Win32\(Default)
Of cource this is another futile exercise. I am not allow to write to HKCR! But this issue did not seem to both BDS.
3) Next, with the IDE fully up, I began to test it. It could easily debug a VCL.Win32 HelloWorld application. But a different story when I tried to debug a VCL.Net application. As soon as I pressed the Run menu, it popped up an assertion failure dialog box (could Borland been shipping debug version of their C++ packages?)
Like this:
My machine, prior to installing D2006, has every version of .Net Frameworks installed, include 3.5 as well as all version of Visual Studio. .Net Framework are by design to support side-by-side installation and hence should be able to live in harmony. Pressing OK brought BDS crashing down instantly.
A search of Google brought me into contact with a report of this problem in Borland's Developers Network's Quality Central. You can find my rather less drastic and more .Net correct solution to this problem posted as a reply to the brutal solution offered on the Quality Central.
After the simple addition of a .Net Config file to rmtdbg100.exe, the IDE can then debug .Net application.
Incidentally, if you are building .Net COM component to be used in say Excel, make sure you give Excel an application config file to set the supported run time, otherwise, your component may fail to load because one that loads before you could change the CLR version to become incompatible with yours.
4) These operations did not cause any problem but were observed in the tools. BDS seemed to demand Generic Read/Generic Write whenever it was opening .Net system dcpil, such as System.Xml.Dcpil, etc. When the access was denied for obvious reasons, it then tried to open with Generic Read.
These operations look very strange and highly inefficient. It should demand the lease privilege particularly in a non-installation situation. Very strange. Not only BDS opening DCPIL files like this but BDS did this with other DLLs as well.
5) BDS had trouble executing in an Adminstrative Console. This is one that is constructed from RunAs command with an embedded /Netonly to provide network connectivity. It fired up fine by using the "Run As" from its short cut and from a cmd.
So far, the reason for this misbeviour has eluded me. Since this is the only program that fail to run in my Administrator console, it is not a big deal. One day, the penny will drop and so stay tune.
No comments:
Post a Comment