Re: VB.NET 2008 not backward compatable?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On 2009-04-26, mayayana <mayaXXyana@xxxxxxxxx> wrote:
If you want to see the code, then just say so. I still have it, well at
leat
I'm 95% sure I do :)


It doesn't matter to me. That code was for a
DotNetter. It was a question posted here. I posted
a link to VB code, and said I wasn't sure whether .Net
could do it. You then "took up the gauntlet" that you
imagined I'd thrown down and posted a VBScript example.
But the OP never got .Net code.


That's not completely accurate.

Option Explicit On
Option Strict Off
Option Infer On

Imports System.Text
Imports System.Runtime.InteropServices

Module Module1

Sub Main()
Dim sb As New StringBuilder()

Dim shellApp = CreateObject("Shell.Application")
Dim windows = shellApp.Windows
For Each ie In windows
Dim ieDoc = ie.Document
Dim selectedItems = ieDoc.SelectedItems
For Each fileItem In selectedItems
sb.AppendLine(fileItem.Name)
Marshal.ReleaseComObject(fileItem)
Next
Marshal.ReleaseComObject(selectedItems)
Marshal.ReleaseComObject(ieDoc)
Next
Marshal.ReleaseComObject(windows)
Marshal.ReleaseComObject(shellApp)

Console.Write(sb)
End Sub

End Module

I got that from the thread. I converted your VBScript in to VB.NET. Now, I
don't know if the OP got a complete answer or not... I did say I would try
and translate your code - but, that I probably wouldn't be able to do it for
at least a week..

I didn't see the point in posting that code for an old thread when I did
finally get time. So, like I said - if you want to see the code I'll dig it
up.

Personally I'm not against .Net any more than I'm
against Java. I just find it uninteresting and irrelevant
for my purposes. I don't feel any inclination to have
a competition between VB and VB.Net because I see
them as different tools for different things.

But the VBers are not free to just be disinterested.

Sure you are. Most of our conversations have resulted in you posting
disinformation - not because I care what you do.


Hmmmm... The explanation I see for it implies that VB6
would be out as well -
for largely the same reason, one runtime instance per process.


I don't follow that logic. At this moment I have an Explorer
Bar showing in an open folder, a program open, and an ActiveX
EXE running from a script to resolve the IP addresses of my server
logs -- all written in VB6. There's no problem. I don't see why
I couldn't have a second bar, band, or other shell extension
running. And in fact I've had both the Explorer Bar and a Property
*** Handler, both VB6, running. I also have no problem opening
a FileOpen dialogue as mentioned here:
http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx


The logic is simple. The problem you are refering to has nothing to do with
the ability of .NET to write the actual extension(s). But, the problem has more
to do with the fact that IF the system in question has both the 1.1 and 2.0
runtimes installed there could be a conflict - since you can only load one
instance of the runtime dll into a given process.

So, can you load two different vb runtimes into the same process? For
instance, what stops me from pulling out the old VB5 and writing a shell
extension? Does that lead to a conflict in your VB6 apps?

Like the article says - Unmanaged C++ is really the only safe way to write a
shell extension.

The reason not to do Shell extensions in .Net, as
I understand it, is because of the problem noted in that
link, and also because there could be a "race to be first" --
if two shell extensions are written on different .Net
runtimes then only one can load. The VB6 runtime, as you

This problem only exists between the 1.0/1.1 runtimes and 2.0 runtime.

know, is just a DLL, not a "framework". But either way, it's
not an issue of loading multiple runtimes. It's an issue of
loading multiple versions.

VB5/VB6? The framework is not the issue - it's the runtime.

--
Tom Shelton
.

Quantcast