I have a WPF C# app which I have created which uses an Access Database (accdb).
I am using Inno for an installer.
I currently have a static path the database in my app.config connectionString section, however what I need is to:
run INNO
ask if this is the Master
YES: install the DB file in C:/MyApp
NO: do not install the DB file, but messageBox asking for the database location (BROWSE and verify Name) - as they will have to look on network.
This browse location answer would then replace the C:/MyApp with //192.168.1.2/C/MyApp for example in the AppConfig connection string section...
Does that sound reasonable or possible (or even 'correct' to do?)
I'm new to C# and this is my first install/deploy I've done so I am very fresh on this.
The other option I was looking at would be to ask to install the database.
If they say NO then just carry on with install.
When the wpf starts up and cant locate the database then I can code in a browse feature in the app which then writes to the appconfig file.
Which is the more Correct way to proceed or is there another option which I am oblivious to which is how it should be done?
Aside from correctness, one advantage to picking the DB location in the app is if the location ever changes. If you do it in the installer, they would have to reinstall.
I would probably go with installing the app as "master" by default, but also provide an option for the user to change this. Then the installer is simplified and doesn't really have to contain any application logic.
Related
My backend is on a cloud server and my frontend will be a MDE file. My company now uses Access2013 but when the database was being designed and coded, we were still on XP.
I am hoping to be able to email all the users a file which will enable auto-updating of the MDE. The examples I have seen require access to the backend. While I do not wish to reinvent the wheel, especially as my only programming knowledge is some VBA, I am hoping to create a file that will:
Check if the path C:\Program Files\myDatabaseFolder exists
If not then create it and copy the MDE from my department server (not the
cloud).
(Possibly also copy a self-certificate to get past the
Trusted Source warning)
If Path exists then check the date modified of the current version
against the version on the department server and retain the latest.
Then Open the Database
There are a few things I'm not too clear on - this file I would email to users and get them to put it on their desktop. When they wanted to access the database, they would just run this - but should this be a batch file or some other form of executable?
Also, when I created the MDE and tried to open it, I got a warning:- "not possible to determine that this content came from a trustworthy source". I do not want the users to see that on opening the file/database, so would a self-certificate be adequate or is there a way to create a trusted location? I am hoping for as little user interaction as possible - not all are able to follow simple instructions.
Any advice or comments welcomed.
I have set this up in a Citrix environment but it should work with normal desktops as well. It is described in detail here:
FE Deploy Method
The script, I used, happened to be VB Script and can be found here:
FE Deploy Script
I didn't have to charge a consulting fee for this.
PS: If you meet a request for signing up at EE, you should be able to just browse past it.
Link to script:
Download script
I have a question regarding a WinForm application and ClickOnce Deployment.
Currently, I use the Visual Studio Installer for creating my installer. One of the things that I do is I have created a custom installer class that I use for entering in certain information (servername, database name, username, password, port number - which is needing for my connection string to the DB). This information gets written to my app config file. However, this makes updates a pain, so I am looking into ClickOnce Deployment instead.
For those of you that do something similar, what's the best way to go about handling this? Is it possible for me to include a config file with my ClickOnce Deployment project that will just copy the settings from that file during the installation? Or, what is the recommend best practice for handling this?
Thanks everyone.
My ClickOnce application also accesses a database. I created a separate program that asks for the database information and encrypts it into a .DAT file. The .DAT file is added to the main program. You must change a setting on the file to Content so that it is included in deployment. The main program opens the .DAT file and decrypts it for the information. This way no one that uses the program knows any of the database information.
I have a winforms solution with multiple projects (UI, web services, data access). All of these projects have their own app.config file. At install time, I need to change the connection string in the data access project based on user's database configuration.
But the data access project creates a dll at install time, with no app.config file available for updating. The UI project is the only project with an app.config file created. And the UI project has a reference to the data access project, so I don't believe the data access project can "see" the config settings of the UI project.
I have searched SO for an answer but have not found anything specific to this situation. Am I doing something wrong in how my projects are set up? Any help would be appreciated.
For anyone else facing this issue:
I believe I found the answer here
In Visual Studio, on the properties of each config file, you can choose "Copy Always" for Copy to Output Directory. This will explicitly create the config file for dll projects.
Then in InstallShield, you can refer to this config file ("MyApplication.dll.config" for example), and alter the connection string through the "Text File Changes" section under "System Configuration". When the user is prompted to connect to a sql server, InstallShield can use those connection properties to alter the connection string in the config file.
OK, so I did the dumb thing and released production code (C#, VS2010) that targeted our development database (SQL Server 2008 R2). Luckily we are not using the production database yet so I didn't have the pain of trying to recover and synchronize everything...
But, I want to prevent this from happening again when it could be much more painful. My idea is to add a table I can query at startup and determine what database I am connected to by the value returned. Production would return "PROD" and dev and test would return other values, for example.
If it makes any difference, the application talks to a WCF service to access the database so I have endpoints in the config file, not actual connection strings.
Does this make sense? How have others addressed this problem?
Thanks,
Dave
The easiest way to solve this is to not have access to production accounts. Those are stored in the Machine.config file for our .net applications. In non-.net applications this is easily duplicated, by having a config file in a common location, or (dare I say) a registry entry which holds the account information.
Most of our servers are accessed through aliases too, so no one really needs to change the connection string from environment to environment. Just grab the user from the config and the server alias in the hosts file points you to the correct server. This also removes the headache from us having to update all our config files when we switch db instances (change hardware etc.)
So even with the click once deployment and the end points. You can publish the a new endpoint URI in a machine config on the end users desktop (I'm assuming this is an internal application), and then reference that in the code.
If you absolutely can't do this, as this might be a lot of work (last place I worked had 2000 call center people, so this push was a lot more difficult, but still possible). You can always have an automated build server setup which modifies the app.config file for you as a last step of building the application for you. You then ALWAYS publish the compiled code from the automated build server. Never have the change in the app.config for something like this be a manual step in the developer's process. This will always lead to problems at some point.
Now if none of this works, your final option (done this one too), which I hated, but it worked is to look up the value off of a mapped drive. Essentially, everyone in the company has a mapped drive to say R:. This is where you have your production configuration files etc. The prod account people map to one drive location with the production values, and the devs etc. map to another with the development values. I hate this option compared to the others, but it works, and it can save you in a pinch with others become tedious and difficult (due to say office politics, setting up a build server etc.).
I'm assuming your production server has a different name than your development server, so you could simply SELECT ##SERVERNAME AS ServerName.
Not sure if this answer helps you in a assumed .net environment, but within a *nix/PHP environment, this is how I handle the same situation.
OK, so I did the dumb thing and released production code
There are a times where some app behavior is environment dependent, as you eluded to. In order to provide this ability to check between development and production environments I added the following line to global /etc/profile/profile.d/custom.sh config (CentOS):
SERVICE_ENV=dev
And in code I have a wrapper method which will grab an environment variable based on name and localize it's value making it accessible to my application code. Below is a snippet demonstrating how to check the current environment and react accordingly (in PHP):
public function __call($method, $params)
{
// Reduce chatter on production envs
// Only display debug messages if override told us to
if (($method === 'debug') &&
(CoreLib_Api_Environment_Package::getValue(CoreLib_Api_Environment::VAR_LABEL_SERVICE) === CoreLib_Api_Environment::PROD) &&
(!in_array(CoreLib_Api_Log::DEBUG_ON_PROD_OVERRIDE, $params))) {
return;
}
}
Remember, you don't want to pepper your application logic with environment checks, save for a few extreme use cases as demonstrated with snippet. Rather you should be controlling access to your production databases using DNS. For example, within your development environment the following db hostname mydatabase-db would resolve to a local server instead of your actual production server. And when you push your code to the production environment, your DNS will correctly resolve the hostname, so your code should "just work" without any environment checks.
After hours of wading through textbooks and tutorials on MSBuild and app.config manipulation, I stumbled across something called SlowCheetah - XML Transforms http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5 that did what I needed it to do in less than hour after first stumbling across it. Definitely recommended! From the article:
This package enables you to transform your app.config or any other XML file based on the build configuration. It also adds additional tooling to help you create XML transforms.
This package is created by Sayed Ibrahim Hashimi, Chuck England and Bill Heibert, the same Hashimi who authored THE book on MSBuild. If you're looking for a simple ubiquitous way to transform your app.config, web.config or any other XML fie based on the build configuration, look no further -- this VS package will do the job.
Yeah I know I answered my own question but I already gave points to the answer that eventually pointed me to the real answer. Now I need to go back and edit the question based on my new understanding of the problem...
Dave
I' assuming yout production serveur has a different ip address. You can simply use
SELECT CONNECTIONPROPERTY('local_net_address') AS local_net_address
I am in the process of writing an offline-capable smartclient that will have syncing capability back to the main backend when a connection can be made. As a side note, I considered the Microsoft Sync Framework but since I'm really only going one-way I didn't feel it would buy me enough to justify it.
The question I have is related to SQLite vs. SQLCE and ClickOnce deployments. I've dealt with SQLite before (impressive little tool) and I've dealt with ClickOnce, but never together. If I setup an installer for my app via ClickOnce, how do I ensure during upgrades the local database doesn't get wiped out? Is it possible to upgrade the database (table structure, etc. if necessary) as part of the installer? Or is it better to use SQLCE for something like this? I definitely don't want to go the route of installing SQL Express or anything as the overhead would be far too high for what I am doing.
I can't speak about SQLLite, having never deployed it, but I do have some info about SQLCE.
First, you don't have to deploy it as a prerequisite. You can just include the dll's in your project. You can check this article which explains how. This gives you finite control over what version is being used, and you don't have to deal with installing it per se.
Second, I don't recommend that you deploy the database as a data file and let ClickOnce manage it. When you change that file, ClickOnce will publish it again and put it in the data directory. Then it will take the previous one and put it in the \pre subfolder, and if you have no code to handle that, your user will lose his data. So if you open the database file to look at the table structure, you might be unpleasantly surprised to get a phone call from your user about the data being gone.
If you need to retain the data between updates, I recommend you move the database to the [LocalApplicationData] folder the first time the application runs, and reference it there. Then if you need to do any updates to the structure, you can do them programmatically and control when they happen. This article explains how to do this and why.
The other advantage to putting the data in LocalApplicationData is that if the user has a problem and has to uninstall and reinstall the application, his data is retained.
Regardless of the embedded database you choose your database file (.sqlite or .sdf) will be a part of your project so you will be able to use "Build Action" and "Copy to Output Directory" properties of that file to control what happens with the file during the install/update.
If you choose "Do not copy" it will not copy the database file and if you choose "Copy if newer" it will only copy if you have a new version of your database file.
You will need to experiment a little but by using these two properties you can have full control of how and when your database file is deployed/updated...