Sunday, April 07, 2002
|
I got the following. I am too busy writing a Wrox article to try them today. I cannot post to the mailing so this way:
I had the same problem as you. My Solution:
Use linkd.exe from the resoutce kit to build a symbolic link.
change to c:program files
execute
C:Program Files> linkd msdotnet "Microsoft Visual Studio .NET"
then set your LIB and INCLUDE environment variables accordingly
That worked for me.
Alternatively
Copy your lib/include directory to a new place
then set your LIB and INCLUDE environment variables accordingly
Or
write a short program that sets the short name using the SetFileShortName API call (this one is new in XP)
1:20:27 PM  |
Ingo documents our work (via Messenger) from last night on my Rotor woes. Info: Rotor needs short filenames!. Sam's Rotor woes continue but we finally found the reason for his problems. Here's the thing everyone should check before playing around with Rotor .... else you might end up with some mysterious error messages. [WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Neither Microsoft nor I can guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. ] Start RegEdt32.Exe and go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem. Check the entry NtfsDisable8dot3NameCreation. It should be set to 0 [zero]. If it has been set to 1 while installing Visual Studio.NET, you may be out of luck with Rotor. To make sure, you should open a command prompt, go to C:Program Files (or wherever you installed VS.NET) and run "dir /x micro*". If a line like this is included in the output, everything should be ok: 20.01.2002 13:01 If you don't see anything that looks like "MICROS~1.NET" next to "Microsoft Visual Studio.NET" you might have the problem. In this case you should change NtfsDisable8dot3NameCreation to 0 [that is: zero], reboot, de-install Visual Studio.NET, manually delete Program FilesMicrosoft Visual Studio.NET (if it still exists; but backup anything interesting before doing so). Then you can re-install it and the necessary short name (DOS-style 8.3 file name) will be created for this directory. I'm currently looking for a better solution to this problem: Does anyone know any tool that allows to create a short filename for a file or directory that already exists? I got one suggestion: did u try to boot into command prompt of xp? u can install it via the xp cd. I think it triggers the shortfile generation according to the local registry, I'm not sure. any way you could do a safe move command without the os locking files the vs.NET folder.. have fun, yosi 10:39:41 AM |
Peter picks up on the discussion:
Sam Gentile: "Is .NET COM Interop fundamentally flawed?" Not sure I agree that it's fundamentally flawed, but it's definitely substantially more complex than the commonly cited "just use TlbImp.exe" story. After all, how simple can it be if there's a 900 page book on the topic? Sam's been doing a lot more COM Interop work than I have, so I'm inclined to listen to him in this regard.
[Peter Drayton's Radio Weblog]
Ahh, but it's not a 900 page book, it's a 1608 page book-))) But that really isn't the main point I am trying to make. Certainly, one of the points to be made is that it is "definitely substantially more complex than the commonly cited "just use TlbImp.exe" story." I think we can all agree on that, right? But that is not the main point I am making. The main point is that the world of COM is determinstic, right? Interface pointers must be released at the right times or you will get memory leaks (at the least) and crashes (at the worst and more likely). My main point is all of this cruft should have been totally hidden by the tlbimp.exe/RCW/CCW mechanism and it isn't. We have had 3 very smart engineers (COM experts) on these problems for 2 months and we are facing things that Microsoft even has no idea on (i.e. things that are not even in that 1608 page book!. This leads me to think that COM Interop was designed for the "textbook" COM case and if you are doing anything else or non-trivial, you will have big, big problems. Microsoft says "You should never need to explicitly release anything unless keeping it alive would cause some sort of issue. Eventually the GC will collect the RCW and the underlying COM object will be released at that point." Wrong, oh so wrong. Major COM architectures don't work that way. There are custom marshalling schemes. There are callbacks and connection points. And on and on. By forcing us to do tons of Marshal.ReleaseComObject calls and UCOM calls, it goes away from what we think the Interop should be an do. I (and we) subscribe to this view that the RCW should do all of this. By making it act non-determinstically, it doesn't play well with others (in the COM world).
10:08:13 AM
