Re: GAC hell

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hmm... So, you are talking about the CodeDom providers, right? In that case I don't see where "VBScript and WSH" comes from, there is no language provider for unmanaged languages in the framework. All there is, are the language providers for CSharp, VisualBasic, J#, C++ and JScript, but all are producing pure managed CSharp, VB.NET, J#, C++ and JScript.NET code.
Also all CodeDom providers share a common interface, so I don't know exactly what problem you have with "adding references".
Mind to give an example that illustrates your issue?

Willy.


"Fredo" <fredo@xxxxxxxxxxx> wrote in message news:Q9-dnXAW0J5K_l7anZ2dnUVZ_qygnZ2d@xxxxxxxxxxxxxxx
Willy,

Sorry, I think you're misunderstanding. I'm talking about the scripting engines: Microsoft.JScript, Microsoft.Vsa, and Microsoft.VisualBasic.Vsa managed engines, not the Windows scripting host or cscript.exe.

These engines work with managed objects, much in the way WSH works with COM objects, but they're different engines, at least the JScript engine is. The entire (or a vast majority of the) JScript interpreter is managed code. The VBScript seems to be doing a lot of stuff in unmanaged code, so for all I know, they're somehow using WSH underneath, but I doubt it since I don't see how it would deal with managed objects.

So my question has to do with the resolution of referenced managed assemblies, not COM components.


"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message news:%23FxHq6AeIHA.2000@xxxxxxxxxxxxxxxxxxxxxxx
"Fredo" <fredo@xxxxxxxxxxx> wrote in message news:geadnVY7J5Qc0l7anZ2dnUVZ_vyinZ2d@xxxxxxxxxxxxxxx
I'm writing a wrapper for the VBScript and JScript engines in .NET. I'm trying to add a little uniformity where Microsoft has some divergence.

With the JScript engine, you can add references and provide a path to where each DLL is. With the VBScript engine, you can't do that. For DLLs that aren't in the GAC, you have to provide a directory where all the referenced .DLLs are.

To keep the user of the wrapper from having to deal with this, for the VBScript I want to add some code to copy all the references that aren't in the GAC, to a temporary directory. The problem is, how would one programmatically determine which ones are in the GAC and which ones aren't? I know I can go snooping around in \Windows\assembly\GAC, but I wanted ot know if there was a better way of doing this that doesn't require me digging through directories, checking DLL versions and such. I don't know precisely how .NET normally does this and unfortunately, I can't see how the VBScript engine deals with it since that part of the framework code appears to be unmanaged.

Thanks.


The scripting engine is a COM client and COM uses the registry to locate the COM server DLL(s) that contains the components as referred to by the scripts.
Now, for .NET components you want to expose to COM clients, you have a number of options when registering your assembly:
1. you can run regasm without the /codebase command line switch, and you have to install the assembly in the GAC, or
2. you can run regasm with the /codebase switch, and you don't have to install the assembly in the GAC, or
3. you can run regasm without the /codebase switch and install the assembly in the same directory as the client.

Note that the COM client in your case is the scripting engine (cscript.exe) which is found in %windir%\system32 (or %windir%\syswow64), so installing the assemblies with the client is excluded, which leaves you with option 1 and 2. Installing in the GAC is
only a viable option if you have a small number of assemblies used by different clients and client types. Option 2 is preferable when you have a number of assemblies used by a single client (or a limited number of clients). If your component is only used by scripting clients (well.. there is only a single one) then you should definitely go for 2.

Willy.






.

Relevant Pages

  • Re: GAC hell
    ... With the JScript engine, you can add references and provide a path to where each DLL is. ... To keep the user of the wrapper from having to deal with this, for the VBScript I want to add some code to copy all the references that aren't in the GAC, to a temporary directory. ... The scripting engine is a COM client and COM uses the registry to locate the COM server DLLthat contains the components as referred to by the scripts. ... only a viable option if you have a small number of assemblies used by different clients and client types. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: GAC hell
    ... not the Windows scripting host or cscript.exe. ... objects, but they're different engines, at least the JScript engine is. ... assemblies, not COM components. ... The scripting engine is a COM client and COM uses the registry to locate ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Have you had good results with Trend Micro support?
    ... I had the same problem with server pattern would not update but all else ... would (the new 8.5 engine was installed on all servers and clients). ... XP/Vista clients and the SBS2k3R2 standard server software to include the ... server client, MSA and security server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Have you had good results with Trend Micro support?
    ... customers are having issues with the new VSAPI 8.500.0.1002 engine on their ... running using the latest scan engine and it updates the server fine but all ... It's the SBS server's TM Client ... that it occurred around the time the virus engine was updated. ...
    (microsoft.public.windows.server.sbs)
  • Re: Have you had good results with Trend Micro support?
    ... "Our developers have checked the issue and has a hotfix for the said ... It worked on my server. ... would (the new 8.5 engine was installed on all servers and clients). ... server client, MSA and security server. ...
    (microsoft.public.windows.server.sbs)