Suggestions on deploying VB.NET app via Network share?

[tendim]

G'day group.

Currently our organization us using VB6 based applications, and I am
trying to push forward and migrate some of the smaller things to
VB.NET, eventually migrating all applications from VB6 and other legacy
languages/systems (Pure VBScript, DataEase, etc.) over to .NET.

Currently, *all* user data is stored on network shares. When a user
logs in to a workstation, their home drive is mounted from one share,
all of their settings are copied down to the machine, and they are good
to go. The only thing installed on the local HD is the OS itself
(Windows XP SP2) and any "native" applications. Native applications
are controlled by another body in our organization, so smaller programs
that we create ad-hoc must be installed in one of two ways:

- Manually going up to the machine and installing it; we have local
admin rights to machines so we can do this
- Installing the application on a network share, and have the user run
it from there.

The majority of our ad-hoc apps are run from Network shares. This
makes updates a lot easier, since we only have to update one copy and
everyone gets it.

Now, I've been attempting to do some things with .NET, but run into
problems because we use network shares everywhere, so I keep getting
security issues since nothing is run from the local HD. Even my
development environment uses network shares to store data, so I can't
develop in the local HD. I did some experimenting and managed to
create Interop assemblies for COM stuff that we are currently using,
copying them to the local HD (C:\tmp\Interop for example) and setting
my .NET references to those local copies. However, this means that for
an update I'd have to go to each machine and update the local Interops.

To sum up my problem(s):

- We use a number of COM objects from third-parties
- 99% of our stuff is stored on Network shares
- We'd like to go .NET
- We'd like to simplify management of upgrades to software
- We don't have rights to change the security levels for different
zones

Can anyone make some suggestions how I can go about doing the above?

>From what I've read, COM objects have to be wrapped by Interop

assemblies before they can be used by .NET. Those assemblies can not
be on a network share in our case due to the zone security settings.

Thanks for any input.

-Patrick

[Norman Yuan]

The security issue of running .NET code that from outside of the running
computer does not mean you cannot do that. It means you have to configure
your system correctly: make the .NET code run safely.

By default, .NET consider any code which is not located/installed on the
machine as unsafe code a,d does not allow it to run, such as the code you
downloaded from the net, from the network share. You can configure your
computer to give certain trust to certain code source, such as trusted
website, a folder on the network share, or even whole intranet, the Internet
(you wouldn't trust whole Internet, would you?).

In your case, you can create a code group, which points to a folder on the
network share, give it full or partial trust (as your apps requires). Then
you can run your .NET from there.

Which version of .NET are you targeting? For 1.X, you go to Control
Panel->Administrati ve Tools->Microsoft .NET Framework 1.x Configuration
applet to configure a machine's .NET security setings. Or you can use
CAPOL.exe tool that comes with .NET framework. YOu may need to do some study
on how to do that.

With 2.0, unfortunately, there is no GUI tool (Microsoft .NET Framework 2.0
Configuration applet is only available if you have .NET2.0 SDK installed,
meaning only .NET developers have it), you have to use command line tool
CAPOL.exe.

<te****@gmail.c omwrote in message
news:11******** *************@p 79g2000cwp.goog legroups.com...

G'day group.

Currently our organization us using VB6 based applications, and I am
trying to push forward and migrate some of the smaller things to
VB.NET, eventually migrating all applications from VB6 and other legacy
languages/systems (Pure VBScript, DataEase, etc.) over to .NET.

Currently, *all* user data is stored on network shares. When a user
logs in to a workstation, their home drive is mounted from one share,
all of their settings are copied down to the machine, and they are good
to go. The only thing installed on the local HD is the OS itself
(Windows XP SP2) and any "native" applications. Native applications
are controlled by another body in our organization, so smaller programs
that we create ad-hoc must be installed in one of two ways:

- Manually going up to the machine and installing it; we have local
admin rights to machines so we can do this
- Installing the application on a network share, and have the user run
it from there.

The majority of our ad-hoc apps are run from Network shares. This
makes updates a lot easier, since we only have to update one copy and
everyone gets it.

Now, I've been attempting to do some things with .NET, but run into
problems because we use network shares everywhere, so I keep getting
security issues since nothing is run from the local HD. Even my
development environment uses network shares to store data, so I can't
develop in the local HD. I did some experimenting and managed to
create Interop assemblies for COM stuff that we are currently using,
copying them to the local HD (C:\tmp\Interop for example) and setting
my .NET references to those local copies. However, this means that for
an update I'd have to go to each machine and update the local Interops.

To sum up my problem(s):

- We use a number of COM objects from third-parties
- 99% of our stuff is stored on Network shares
- We'd like to go .NET
- We'd like to simplify management of upgrades to software
- We don't have rights to change the security levels for different
zones

Can anyone make some suggestions how I can go about doing the above?

>>From what I've read, COM objects have to be wrapped by Interop

assemblies before they can be used by .NET. Those assemblies can not
be on a network share in our case due to the zone security settings.

Thanks for any input.

-Patrick

[tendim]

Norman Yuan wrote:

The security issue of running .NET code that from outside of the running
computer does not mean you cannot do that. It means you have to configure
your system correctly: make the .NET code run safely.

This I know.

By default, .NET consider any code which is not located/installed on the
machine as unsafe code a,d does not allow it to run, such as the code you
downloaded from the net, from the network share. You can configure your
computer to give certain trust to certain code source, such as trusted
website, a folder on the network share, or even whole intranet.

This too.

In your case, you can create a code group, which points to a folder on the
network share, give it full or partial trust (as your apps requires). Then
you can run your .NET from there.

The problem is that if I go this route, I have to go to each computer
in our organization (over 100) and manually configure them to trust
that code group, don't I? To make matters worse, since someone else
manages the network, they have locked down many of the security
features and configurable options in XP.

>
Which version of .NET are you targeting?

VB.NET 2.0, from the latest MSDN CD's (VS 2005 Pro from the Dec/2005
disc-set).

With 2.0, unfortunately, there is no GUI tool (Microsoft .NET Framework 2.0
Configuration applet is only available if you have .NET2.0 SDK installed,
meaning only .NET developers have it), you have to use command line tool
CAPOL.exe.

I've probably got that disc kicking around in these MSDN binders, I'll
see if I can find it.

Short of creating a trusted code group, am I SOL? Does the security
only apply to shared libraries and the like? For arguments sake, if I
had a one-file executable compiled statically, and ran that straight
from a network share, would it work at all?

[Sorry if I've horribly mangled some terminology -- I took a .NET
course a year ago and havne't touched .NET since! The learning curve
has been steep the past few days but it's all coming back now.
Unfortuantely the course didn't cover much in the way of deployment.]

Thanks,
Patrick

[Cor Ligthert [MVP]]

Tendim,

Did you ever made a document longer than this message "Why I have everything
on Shares?"

Mostly is this a habbit from the time that the Hard Disk was very expensive
(about 25 years ago) to buy, so a lot of Lan inventors have sold that as a
cheap way to use Disk. People still believe that it is a good idea to do
that.

Data should be on a Server because of security, sharing and backup reasons.
A copy of a program can be everywhere, the best as thight to the processor
as possible to save high LAN costs and backup trouble.

Just my thought,

Cor

<te****@gmail.c omschreef in bericht
news:11******** *************@p 79g2000cwp.goog legroups.com...

G'day group.

Currently our organization us using VB6 based applications, and I am
trying to push forward and migrate some of the smaller things to
VB.NET, eventually migrating all applications from VB6 and other legacy
languages/systems (Pure VBScript, DataEase, etc.) over to .NET.

Currently, *all* user data is stored on network shares. When a user
logs in to a workstation, their home drive is mounted from one share,
all of their settings are copied down to the machine, and they are good
to go. The only thing installed on the local HD is the OS itself
(Windows XP SP2) and any "native" applications. Native applications
are controlled by another body in our organization, so smaller programs
that we create ad-hoc must be installed in one of two ways:

- Manually going up to the machine and installing it; we have local
admin rights to machines so we can do this
- Installing the application on a network share, and have the user run
it from there.

The majority of our ad-hoc apps are run from Network shares. This
makes updates a lot easier, since we only have to update one copy and
everyone gets it.

Now, I've been attempting to do some things with .NET, but run into
problems because we use network shares everywhere, so I keep getting
security issues since nothing is run from the local HD. Even my
development environment uses network shares to store data, so I can't
develop in the local HD. I did some experimenting and managed to
create Interop assemblies for COM stuff that we are currently using,
copying them to the local HD (C:\tmp\Interop for example) and setting
my .NET references to those local copies. However, this means that for
an update I'd have to go to each machine and update the local Interops.

To sum up my problem(s):

- We use a number of COM objects from third-parties
- 99% of our stuff is stored on Network shares
- We'd like to go .NET
- We'd like to simplify management of upgrades to software
- We don't have rights to change the security levels for different
zones

Can anyone make some suggestions how I can go about doing the above?

>>From what I've read, COM objects have to be wrapped by Interop

assemblies before they can be used by .NET. Those assemblies can not
be on a network share in our case due to the zone security settings.

Thanks for any input.

-Patrick

[tendim]

Hi Cor.

Cor Ligthert [MVP] wrote:

Data should be on a Server because of security, sharing and backup reasons.
A copy of a program can be everywhere, the best as thight to the processor
as possible to save high LAN costs and backup trouble.

I agree, but from a maintanence perspective that is over 100 machines
that would have to be physically updated on a weekly basis due to code
changes and the like; we are a very active site with changes occuring
continuously due to outside specifications outside of our control. :(

If I could figure out a way to push changes down automatically to the
computers on a daily/weekly basis, that would be sufficient as well.
Unfortuantely I don't think anyone on our site has security to do so
from a network-administrative perspective.

Thanks,
-p

[Cor Ligthert [MVP]]

Tending,

Ever looked at the "Click once" technique or whatever name there is used for
that.

Microsoft is updating every month probably many million computers. The
technique is the same as you can use.

http://msdn.microsoft.com/msdnmag/is...e/default.aspx

I took the first article I could find, I did not read it, it is one of
thousands

Cor

<te****@gmail.c omschreef in bericht
news:11******** **************@ i3g2000cwc.goog legroups.com...

Hi Cor.

Cor Ligthert [MVP] wrote:

>Data should be on a Server because of security, sharing and backup
reasons.
A copy of a program can be everywhere, the best as thight to the
processor
as possible to save high LAN costs and backup trouble.

I agree, but from a maintanence perspective that is over 100 machines
that would have to be physically updated on a weekly basis due to code
changes and the like; we are a very active site with changes occuring
continuously due to outside specifications outside of our control. :(

If I could figure out a way to push changes down automatically to the
computers on a daily/weekly basis, that would be sufficient as well.
Unfortuantely I don't think anyone on our site has security to do so
from a network-administrative perspective.

Thanks,
-p

[Norman Yuan]

I agree with Cor.

I only place some very simply .NET Winform apps that are used occasionally
on our office's network share. and make one specific entry on the new
computer setup checklist that will make sure a specific code group is set up
and pointing to that network share.

But, for any regular .NET Winform app, I use "Click Once" to deploy since
..NET2.0, it make deployment and update very enjoyful, seeing that whenever
user starts my app, he alway gets the latest version auotmatically.

<te****@gmail.c omwrote in message
news:11******** **************@ i3g2000cwc.goog legroups.com...

Hi Cor.

Cor Ligthert [MVP] wrote:

>Data should be on a Server because of security, sharing and backup
reasons.
A copy of a program can be everywhere, the best as thight to the
processor
as possible to save high LAN costs and backup trouble.

I agree, but from a maintanence perspective that is over 100 machines
that would have to be physically updated on a weekly basis due to code
changes and the like; we are a very active site with changes occuring
continuously due to outside specifications outside of our control. :(

If I could figure out a way to push changes down automatically to the
computers on a daily/weekly basis, that would be sufficient as well.
Unfortuantely I don't think anyone on our site has security to do so
from a network-administrative perspective.

Thanks,
-p