0

we have a .net windows forms application and for years we have been using the Visual Studio setup projects to build our msi installers. We have settings stored in the registry and also in the user profiles. The problem we have got is that our users work in very restricted environments mainly in the banking sector and have no permissions to do anything at all. Best case scenario they have access to the folder where the app is installed. So every time they need to upgrade our application they need to get IT involved which involves months waiting and ridiculous costs.

So here is the idea, we thought of storing all user and application settings in the application folder and install by simply copying and pasting the necessary files to the right directory. We don't have any dependencies or COM dlls, no need to register anything. The idea is that the deployment works similar to the Eclipse copy and paste install or Mac OS X applications. No need to put things in the registry, no need to use installers just copy and paste a folder. So are there any people out there who have tried this strategy and what do you think are the drawbacks?

Dimitris
  • 2,030
  • 3
  • 27
  • 45
  • 1
    Basically, yes. One of my products on first run will look for the configuration file and if not found, it will copy the default file to the required location. Presumably your application can use the Settings location (Application Data)? In this case it should be generated with appropriate defaults. – Robinson Mar 12 '12 at 11:16
  • OK I was thinking to avoid Application Data simply so that the app is not dependent on anything at all. – Dimitris Mar 12 '12 at 11:18
  • ClickOnce would be good here as its installed to appdata in the user profile (except for your registry settings which will still need admin-access to edit no matter what solution you choose) – undefined Mar 12 '12 at 11:19
  • Hmmm I would like to avoid as much as possible storing anything in the user profiles. – Dimitris Mar 12 '12 at 11:20

2 Answers2

2

Putting settings into the application folder is generally a very bad idea (especially in environments where security matters). The reason for this is that your users would need write-access to the application folder which would enable them to modify executables.
In addition, private per-user settings are not realizable as everyone would see the settings of every user.

User Profiles (see C# getting the path of %AppData% ) are the best location to store those settings. You should tell your customer that this "copy-deployment" would actually worsen security, reliability and maintainability.

Community
  • 1
  • 1
Matthias
  • 12,053
  • 4
  • 49
  • 91
  • I see, I did wonder if there would be security issues with this approach. So you recommend doing everything with the user profiles? – Dimitris Mar 12 '12 at 11:24
  • This really depends on the application: Should it be used by multiple users? If yes: What should happen if two users share one computer but have their own user-profiles? If they shouldn't share the settings in this case, you have to store the settings in the user profile. - What should happen if one user logs into another machine? Should settings be synced? ... - In general, however, it's common to restrict the user's access rights of everything which might affect other users (e.g. Windows directory, program directory, ...) and store user-specific data inside the profiles. – Matthias Mar 12 '12 at 11:33
  • ok thanks it makes sense. Unfortunately in the finance industry there are many restrictions which we have to accept. – Dimitris Mar 12 '12 at 11:39
1

It is an acceptable approach that is widely used with the name called "Portable". The portable applications require no installation, instead just coping application DLLs and dependencies in a single folder. You may go ahead as long as it completely suits your production environment.

Karthick Arun
  • 301
  • 2
  • 7