There is a legacy app that I have to make an edit to via VS, but I'm not sure what the process involves in recompiling the program. Since nothing else uses VS as it's just an app gluing together some things that support a legacy system, I rarely use it so I apologize for the unfamiliarity in how it works.
A while ago I lost everything on one side of my computer so I had to copy the app folder from the server that contains the entire app. As of right now I am in the .cs file where I need to update the connection string, because the database it connected to has been changed. Unfortunately anytime I make a change to these files I don't have the option to rebuild the whole app. Is this because the copy of the app folder is not recognized as a project locally? What must I do to make these changes and make sure they transfer back to the server?
Related
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.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
I am struggling to make a SqlCE local database to work in my winforms project.
I`m used to work with web app, this is my first desktop app, and after understand a lot of tricks like when you insert data in your local database while debugging, the data goes to a magic database inside bin/debug folder - that I would never wonder by myself - and from yesterday to now, I launch my project again, and guess what the new trick? The database got lost ¬¬ !!
Suddenly my project can't recognize its own path to the database and it throws me an error: "The path is not from a legal form", I SWEAR I didn't move the mouse from yesterday when it was working from now.
Anyway, SqlCE gave me a lot of headaches already, I'm doing this project as a favor to a bookstore inside a charity house and I'd like this project gets only one weekend - it already didn't.
So, as I don`t have a big amount of data to store, what would be the alternatives to store this data without a .sdf file?
If you want to stay with SQL I would recommend SQLite. Small, lightweight and results are placed in a single file.
http://sqlite.org/
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...
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.