Some issues

May 13, 2008 at 12:52 PM
Edited May 14, 2008 at 10:59 AM
The shell extension part is too written in C# (requiring .NET).
But you must not write shell extensions in .NET! Ever!
I already had two apps stopped working after installing LizardTF because of this.

Also, since I also use TortoiseSVN and even have TortoiseCVS installed (some of our projects are very old and still in CVS), the overlays don't show up.
Have you considered using the new overlay handler TortoiseSVN provides for all Tortoise clients?
http://tortoisesvn.tigris.org/svn/tortoisesvn/TortoiseOverlays/version-1.0.4/Documentation.txt
(username: "guest", leave password empty)


Coordinator
May 15, 2008 at 12:11 PM
Edited May 15, 2008 at 1:13 PM
You are right, but I would say 'should not' rather than 'must not' :)

I do plan to replace the shell extentions with c++ ones (or if anyone else fancies the job, please let me know) but probably not for a while.

I was hoping the 2.0.50727 CLR would run 1.0 and 1.1 code okay, and problems would not arrise. You shouldn't get the problem if LizardTF is the only app doing this, what were the other apps, do they also guilty and do they load a CLR into the shell? Or are there further, more sinister, issues at stake?

I was also waiting to see if the mini CLR used by Silverlight could be used (this does/will allow multiple versions to be loaded, as IE will have to support different Silverlight apps at once) which could avoid the issue. I've not read much about this yet, but it could be really useful if MS haven't made it a closed off thing.

(This article http://blogs.msdn.com/jasonz/archive/2007/05/10/side-by-side-in-process-clrs-start-with-silverlight.aspx makes it look quite promising)

Also, yes you are quite right about the overlays, Windows only allows 15. I will read the article you link to! (My current system was based on reading the Tortoise code, but that was a while ago) I was also considering using a Desktop.ini to get a 'special' view of source controlled folders, but this might suck.

At the moment I'm finishing of getting the history to follow branches, then I must add 'Move' and 'Rename' which I only noticed were missing the other day, when I needed them.

Thanks for the input,

Ian.




harrihasler wrote:
The shell extension part is too written in C# (requiring .NET).
But you must not write shell extensions in .NET! Ever!
I already had two apps stopped working after installing LizardTF because of this.

Also, since I also use TortoiseSVN and even have TortoiseCVS installed (some of our projects are very old and still in CVS), the overlays don't show up.
Have you considered using the new overlay handler TortoiseSVN provides for all Tortoise clients?
http://tortoisesvn.tigris.org/svn/tortoisesvn/TortoiseOverlays/version-1.0.4/Documentation.txt
(username: "guest", leave password empty)





Coordinator
May 15, 2008 at 10:37 PM
Okay, so the silverlight CLR won't/doesn't have COM interop. obviously this would be a somewhat lunatic thing to put in a runtime framework designed for anonymous downloaded applications...

so I'll have to write some c++ and use some COM invocation of Lizard. bah.

If this is anyones idea of fun, please let me know. I will code up a COM interface for you.

I think that if *all* apps that use .Net shell extentions are open source, then you should be able to build them all with the same CLR, then use them without worry! but back to the real world.....

I'll keep thinking about this one.

Ian.
Coordinator
May 15, 2008 at 10:45 PM


Have you considered using the new overlay handler TortoiseSVN provides for all Tortoise clients?
http://tortoisesvn.tigris.org/svn/tortoisesvn/TortoiseOverlays/version-1.0.4/Documentation.txt
(username: "guest", leave password empty)


I have just quickly read this, and yes, it sounds like a good idea to have it as an option. Some of the Lizard Icons are a bit different (changed but not checked out, for example as this can't happen in SVN) so I'd like to keep native mode as well.

Thanks again,

Ian.
May 16, 2008 at 8:56 AM


SmallWalrus wrote:
You are right, but I would say 'should not' rather than 'must not' :)

I do plan to replace the shell extentions with c++ ones (or if anyone else fancies the job, please let me know) but probably not for a while.

I was hoping the 2.0.50727 CLR would run 1.0 and 1.1 code okay, and problems would not arrise. You shouldn't get the problem if LizardTF is the only app doing this, what were the other apps, do they also guilty and do they load a CLR into the shell? Or are there further, more sinister, issues at stake?

I was also waiting to see if the mini CLR used by Silverlight could be used (this does/will allow multiple versions to be loaded, as IE will have to support different Silverlight apps at once) which could avoid the issue. I've not read much about this yet, but it could be really useful if MS haven't made it a closed off thing.

(This article http://blogs.msdn.com/jasonz/archive/2007/05/10/side-by-side-in-process-clrs-start-with-silverlight.aspx makes it look quite promising)

Also, yes you are quite right about the overlays, Windows only allows 15. I will read the article you link to! (My current system was based on reading the Tortoise code, but that was a while ago) I was also considering using a Desktop.ini to get a 'special' view of source controlled folders, but this might suck.

At the moment I'm finishing of getting the history to follow branches, then I must add 'Move' and 'Rename' which I only noticed were missing the other day, when I needed them.

Thanks for the input,

Ian.

Well, I would really say "must not". "should not" indicates that you're still allowed to do it - which I think you're not. IMHO you're not allowed to break other applications at all.

The problem with my apps which stopped working:
Those are native apps which for certain features load the .NET framework. Those are usually plugin dlls which are written in .NET while the main app is not. Now, since the main app uses some shell functions (not only file-open/save dialogs load the shell extensions!), LizardTF gets loaded with the main app (and the corresponding CLR). As soon as the main app wants to use one of the plugin dlls written in .NET (which require a different version of the CLR), that won't work anymore because LizardTF already forced loading a different version of the CLR.
It's not just apps that use shell extension - remember that your shell extension gets loaded even if the apps themselves did not ask for it! (For example, a simple call of SHGetFileInfo() loads the extensions - and many apps use that function to get the system image list to show the icons for a file list).

Which is why I can only test LizardTF on a virtual machine for now. I can't have it installed on my main machine.

I don't think you could use Silverlight for this. Silverlight is designed for IE, not the shell.


Coordinator
May 16, 2008 at 12:03 PM
Edited May 16, 2008 at 12:12 PM

Thanks for the more detailed explaination. I hadn't considered that scenario, this is the first time I've really used shell extensions.

'Must not' it is. :(

I think everything except the Property Page should be relatively straight forward ot convert. The worst bit will be writing a transport mechanism to replace the System.Remoting Lizard uses (I needed to completely seperate the shell from the main App anyway to allow 64-bit shells to talk to the 32-bit TFS API) so thankfully the shell extentions are quite detached from the main anyway. Most of the communication is simple string lists and a bit of XML so some basic tcp/ip functions should do or maybe COM+. I'd best get reading...

Any advice gratefully received, 

Thanks,

Ian.

Coordinator
May 20, 2008 at 9:24 AM

Thanks for the more detailed explaination. I hadn't considered that scenario, this is the first time I've really used shell extensions.

'Must not' it is. :(

I think everything except the Property Page should be relatively straight forward ot convert. The worst bit will be writing a transport mechanism to replace the System.Remoting Lizard uses (I needed to completely seperate the shell from the main App anyway to allow 64-bit shells to talk to the 32-bit TFS API) so thankfully the shell extentions are quite detached from the main anyway. Most of the communication is simple string lists and a bit of XML so some basic tcp/ip functions should do. I'd best get reading...

Any advice gratefully received, 

Thanks,

Ian.