T
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?
be on a network share in our case due to the zone security settings.
Thanks for any input.
-Patrick
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?
assemblies before they can be used by .NET. Those assemblies can notFrom what I've read, COM objects have to be wrapped by Interop
be on a network share in our case due to the zone security settings.
Thanks for any input.
-Patrick