471,321 Members | 1,801 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,321 software developers and data experts.

ClickOnce again

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
Jun 27 '08 #1
4 1720
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
Jun 27 '08 #2
"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.
Jun 27 '08 #3
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
Jun 27 '08 #4
"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.
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Chris Rennert | last post: by
3 posts views Thread by Ronald S. Cook | last post: by
1 post views Thread by dongarbage | last post: by
6 posts views Thread by Irfan | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.