ClickOnce again

[=?Utf-8?B?Q2hyaXN0aWFuIEhhdmVs?=]

Hi,

I have a .NET / COM DLL. On the client the COM object is created by a
application using VBScript (Windows Scripting).

I try to deploy the .NET / COM DLL using ClickOnce deployment. I know that
it is only possible to deploy a Windows Forms - no DLL. Well, my idea is to
deploy a "dummy" Windows Forms app, that references the .NET / COM DLL.
The next problem is how to register the .NET / COM DLL on the client. My
next idea was to make the .NET / COM DLL a "reg free COM" object. Could this
work? Can the VBScript create the .NET / COM DLL using CreateObject(..)
without the required informations from the registry?
Could the "dummy" Windows Forms app register the .NET / COM DLL or would I
get some security problems?
Christian

[Marc Gravell]

I know that it is only possible to deploy a Windows Forms - no DLL.

ClickOnce can deploy pretty-much anything (as a flat file) as long as it
stays inside the subtree - i.e. you can't use ClickOnce to deploy to
system32...

My next idea was to make the .NET / COM DLL a "reg free COM" object.

..NET *can* be made to use registry free COM (bundling the dll as a
file), but the configuration is, from all accounts, very involved - and
there arent many tools to help. Personally, I'd need a *very* good
reason before I embarked on that road.

Can the VBScript create the .NET / COM DLL using CreateObject(..)
without the required informations from the registry?

I doubt that VBScript will like registry-free COM.

Could the "dummy" Windows Forms app register the .NET / COM DLL or would I
get some security problems?

Well, it could (asusming full trust) - but unless you are re-running the
application you won't get auto-update etc.

But: from the above, it sounds like you are trying to do something that
is beyond ClickOnce; my first thought would be - so don't use ClickOnce.
There are other ways of managing deployment... an MSI and GPO for
example (or whatever other domain deployment tool you fancy...).

Marc

[Willy Denoyette [MVP]]

"Christian Havel" <Ch************@discussions.microsoft.comwrote in
message news:4D**********************************@microsof t.com...

Hi,

I have a .NET / COM DLL. On the client the COM object is created by a
application using VBScript (Windows Scripting).

I try to deploy the .NET / COM DLL using ClickOnce deployment. I know that
it is only possible to deploy a Windows Forms - no DLL. Well, my idea is
to
deploy a "dummy" Windows Forms app, that references the .NET / COM DLL.
The next problem is how to register the .NET / COM DLL on the client. My
next idea was to make the .NET / COM DLL a "reg free COM" object. Could
this
work?

No, this doesn't work for scripting clients.

Can the VBScript create the .NET / COM DLL using CreateObject(..)

without the required informations from the registry?

No, the component must be registered, the Scripting engine is not able to
find a COM component without it being registered.

Could the "dummy" Windows Forms app register the .NET / COM DLL or would I
get some security problems?

It doesn't matter what you are using to register a .NET component for COM
interop, important is that somehow you register the component. This
registration process always requires the caller to run with administrative
privileges.

Willy.

[=?Utf-8?B?Q2hyaXN0aWFuIEhhdmVs?=]

Thank you Marc for the informations

"Marc Gravell" wrote:

I know that it is only possible to deploy a Windows Forms - no DLL.

ClickOnce can deploy pretty-much anything (as a flat file) as long as it
stays inside the subtree - i.e. you can't use ClickOnce to deploy to
system32...

My next idea was to make the .NET / COM DLL a "reg free COM" object.

..NET *can* be made to use registry free COM (bundling the dll as a
file), but the configuration is, from all accounts, very involved - and
there arent many tools to help. Personally, I'd need a *very* good
reason before I embarked on that road.

Can the VBScript create the .NET / COM DLL using CreateObject(..)
without the required informations from the registry?

I doubt that VBScript will like registry-free COM.

Could the "dummy" Windows Forms app register the .NET / COM DLL or would I
get some security problems?

Well, it could (asusming full trust) - but unless you are re-running the
application you won't get auto-update etc.

But: from the above, it sounds like you are trying to do something that
is beyond ClickOnce; my first thought would be - so don't use ClickOnce.
There are other ways of managing deployment... an MSI and GPO for
example (or whatever other domain deployment tool you fancy...).

Marc

[Willy Denoyette [MVP]]

"Marc Gravell" <ma**********@gmail.comwrote in message
news:e7**************@TK2MSFTNGP03.phx.gbl...

>I know that it is only possible to deploy a Windows Forms - no DLL.

ClickOnce can deploy pretty-much anything (as a flat file) as long as it
stays inside the subtree - i.e. you can't use ClickOnce to deploy to
system32...

My next idea was to make the .NET / COM DLL a "reg free COM" object.

.NET *can* be made to use registry free COM (bundling the dll as a file),
but the configuration is, from all accounts, very involved - and there
arent many tools to help. Personally, I'd need a *very* good reason before
I embarked on that road.

The latest compilers (C# and VB.NET (V2 SP1 and V3.5) do automatically embed
a side_by_side manifest into a .NET assembly required by "reg-free COM".

Can the VBScript create the .NET / COM DLL using CreateObject(..)
without the required informations from the registry?

I doubt that VBScript will like registry-free COM.

For "Reg-free COM" to work, you need a server and a client manifest, and you
need the client and the server to be loaded from the same path. In case of
VBScript (or whatever other script), that would mean that:
- your assembly be installed in System32.
- a client manifest (cscript.exe.manifest) be installed in System32
- the client manifest, must hold the assembly dependencies of a *ALL*
possible components you will ever load in CScript.exe.
So while theoretically possible, it's absolutely unadvisable to install user
application components in system32, also, it would defeat the purpose of
"Reg-free COM", as it would require an administrator to install the assembly
and the client manifest in system32.
Willy.