Home All Groups Group Topic Archive Search About

Simple installation of vb.net apps....

Author
6 Apr 2006 2:34 PM
sam
I use vb.net for in-house development of apps. Many of these apps are
small in size, with few if any referenced dlls. I'd like my apps to be
*totally* self-contained--that is, I want to be able to drag and drop
the contents of the app's directory onto a new machine and have it run
*with no installation procedures*.

In the past (vb.net 2003) this seemed relatively reliable, assuming that
the dotnet framework was in place and that any referenced dlls or
third-party components had their CopyLocal property set to TRUE. Since
switching to vb.net 2006, this does not always seem to be the case. Apps
that I have ported from 2003 to 2006, fail to run with errors like "The
app encountered a problem....blah blah send a report to microsoft".

Is there a 100% accurate manner of making an app totally self-contained
in that it will run on a machine with the (proper) dotnet framework
installed? If not, is there a manner in which a more accurate error
report can be generated on a (non-developer) machine with a bit more
useful information--such as exactly what is missing?

Author
6 Apr 2006 2:45 PM
David Browne
Show quote Hide quote
"sam" <spammenot@gtnincs.com> wrote in message
news:e9F57cYWGHA.3496@TK2MSFTNGP05.phx.gbl...
>I use vb.net for in-house development of apps. Many of these apps are small
>in size, with few if any referenced dlls. I'd like my apps to be *totally*
>self-contained--that is, I want to be able to drag and drop the contents of
>the app's directory onto a new machine and have it run *with no
>installation procedures*.
>
> In the past (vb.net 2003) this seemed relatively reliable, assuming that
> the dotnet framework was in place and that any referenced dlls or
> third-party components had their CopyLocal property set to TRUE. Since
> switching to vb.net 2006, this does not always seem to be the case. Apps
> that I have ported from 2003 to 2006, fail to run with errors like "The
> app encountered a problem....blah blah send a report to microsoft".
>
> Is there a 100% accurate manner of making an app totally self-contained in
> that it will run on a machine with the (proper) dotnet framework
> installed? If not, is there a manner in which a more accurate error report
> can be generated on a (non-developer) machine with a bit more useful
> information--such as exactly what is missing?

ClickOnce
http://msdn.microsoft.com/smartclient/understanding/windowsforms/2.0/features/clickonce.aspx

David
Author
7 Apr 2006 1:52 AM
sam
David Browne wrote:

Unfortunately, clickonce performs an installation per user
(installations being what I'm hoping to avoid in the first place). In
the past, I have placed an app (in it's folder with it's references and
dependencies) on a local machine or even on a linux server and both ran
fine from a windows box.

It only seems to have gotten more unpredictable with 2005 apps. Hence me
need to be able to create a folder containing ALL required materials for
the app.
Author
7 Apr 2006 2:11 AM
David Browne
Show quote Hide quote
"sam" <spammenot@gtnincs.com> wrote in message
news:e$%23U9XeWGHA.4424@TK2MSFTNGP05.phx.gbl...
> David Browne wrote:
>
>> ClickOnce
>> http://msdn.microsoft.com/smartclient/understanding/windowsforms/2.0/features/clickonce.aspx
>>
>
>
> Unfortunately, clickonce performs an installation per user (installations
> being what I'm hoping to avoid in the first place). In the past, I have
> placed an app (in it's folder with it's references and dependencies) on a
> local machine or even on a linux server and both ran fine from a windows
> box.
>
> It only seems to have gotten more unpredictable with 2005 apps. Hence me
> need to be able to create a folder containing ALL required materials for
> the app.

Well nothing has really changed in assembly loading.  If you have the .NET
framework and you copy all the dependant assemblies to the application's
local directory it will all run fine.

David
Author
8 Apr 2006 7:08 PM
sam
David Browne wrote:
\
> Well nothing has really changed in assembly loading.  If you have the .NET
> framework and you copy all the dependant assemblies to the application's
> local directory it will all run fine.


I suppose therein lies the problem--how to determine 100% what the app
is dependent upon.