Application Deployment Issues...

  • Thread starter Thread starter Nisha
  • Start date Start date
N

Nisha

Hi Everyone,

I have a windows application that connects to a SQL server database. I have
the dotnet runtime installed on all the client machines. Instead of
installing the application on every client... I would like to set up the
application on an application server and provide a shortcut on the user
desktops... so basically they are getting onto the application server
through the lan and then connecting to the database server.

My understanding was that this is possible if I configure the code access
security on the app server.. using the Microsoft .net configuration.

I have played around with all the security options with no success at all.
If I try to connect to the app server I the access denied errors on the
system.data.dll which I am assuming is needed for securing the database
connection.. to be specific the error is invalid element :
system.data.common.dbdataPermission.toxml

If the app is locally installed everything is fine.

This is not the greatest scenario.. as for every release... all clients have
to be upgraded.

Any help in this matter would be greatly appreciated.

Thanks,
...Nisha
 
You have to configure these permission on every client machine - you don't
need to do anything on the server.

By default, the permissions for a program that you are running of another
machine, does not include the ability to do database access. So every client
machine that wants to use this program, needs to give this program
permissions (either by URL, or just all intranet apps) to do DB access.
 
Another thing you could try is to write an App Updater.
This is what I do:
The app updater is just a small app that I wrote that expects 3 things: The name of the app that needs updating, its excute path, and the path to the directory where your new build of the app is.
The app that I am wanting to update has a few lines of code that run when the app is started. These lines of code pass the name of the app, its executable path and the path of the directory where the new build of the app is.
Next a new process (the app updater) is started and the client app waits for it to exit.
The app updater then looks at the last write time of the client executable and compares it to the exe with the same name in the directory where the new build is located. If the new build is newer, the app updater kills the calling app (by way of the name of the app that was passed in), it then copies it over to the client along with any and all files that are in the directory with it. Next the app updater restarts the calling app and kills itself.
By looping through all of the files in the update directory you can copy over newer versions of any dll's for the app as well as any newer ones that may be needed due to something you added to your application.
This works and is pretty simple, but it will not handle situations where you have added something that requires something like a merge module to install files in a location other than that of the application itself.

----- Nisha wrote: -----

Hi Everyone,

I have a windows application that connects to a SQL server database. I have
the dotnet runtime installed on all the client machines. Instead of
installing the application on every client... I would like to set up the
application on an application server and provide a shortcut on the user
desktops... so basically they are getting onto the application server
through the lan and then connecting to the database server.

My understanding was that this is possible if I configure the code access
security on the app server.. using the Microsoft .net configuration.

I have played around with all the security options with no success at all.
If I try to connect to the app server I the access denied errors on the
system.data.dll which I am assuming is needed for securing the database
connection.. to be specific the error is invalid element :
system.data.common.dbdataPermission.toxml

If the app is locally installed everything is fine.

This is not the greatest scenario.. as for every release... all clients have
to be upgraded.

Any help in this matter would be greatly appreciated.

Thanks,
...Nisha
 
Hi Donzo...
Your application updater sounds interesting... however on doing some further
reading... windows active directory can push out updates to client machines
quite easily.

However my intention is not to push out the app to client machines.. but
rather to have client machines run the application off the server for better
maintainability.

Thanks anyways.

Donzo said:
Another thing you could try is to write an App Updater.
This is what I do:
The app updater is just a small app that I wrote that expects 3 things:
The name of the app that needs updating, its excute path, and the path to
the directory where your new build of the app is.
The app that I am wanting to update has a few lines of code that run when
the app is started. These lines of code pass the name of the app, its
executable path and the path of the directory where the new build of the app
is.
Next a new process (the app updater) is started and the client app waits for it to exit.
The app updater then looks at the last write time of the client executable
and compares it to the exe with the same name in the directory where the new
build is located. If the new build is newer, the app updater kills the
calling app (by way of the name of the app that was passed in), it then
copies it over to the client along with any and all files that are in the
directory with it. Next the app updater restarts the calling app and kills
itself.
By looping through all of the files in the update directory you can copy
over newer versions of any dll's for the app as well as any newer ones that
may be needed due to something you added to your application.
This works and is pretty simple, but it will not handle situations where
you have added something that requires something like a merge module to
install files in a location other than that of the application itself.
 
Hi Marina,

Code Access Security in the .NET Framework allows you to configure the
application so that it can be accessed by several clients. By default when
an application is installed, only the local machine has access to the dll's.
CAS allows you to configure the security so that a group of clients can
access the dll's as well. That is what I need to do.

The configuration is to be done at the server level only... not every
client. Logging into the database was never an issue.. its accessing the app
( and the runtime dll's that are loaded when you launch the app) that is the
problem.

Thanks anyways.

...Nisha
 
Back
Top