i've added my database to my source folder and whenever i launch the program it copies the db in my Debug folder but the modifications don't seem to be copied back in my source folder,over the old DB .
How can i do so automatically ?
Since there is no "after execution" script being called when the application dies and you are returned to Visual Studio (as I assume is the case you are talking about) you can create a pre-build script which checks if the DB in the DEBUG folder is newer than the source, and then copies it back before the building.
This way you will get the changes back, although you would be one version behind.
A better solution is to check that the DB is not copied to the output folder, and reference it with an absolute path instead of a relative one. This way you would always work against your live database. (I assume you are using SQL Express)
Three ways:
Put an XCopy command in your Pre-Build event (project->Properties->Build Events). But this will only do it each time you do a build, not after the program has run.
Add code to your program to "back-up" a database to a path you specify in App.config, where that path is your source folder.
Launch your program from a .bat file that copies the DB back to wherever you want when the program exits.
Related
I am trying to develop a feature in my app, which will enable users to check for the updates and, if new version exists (on the FTP server), it will download all the new files and run the new instance of the application.
I have successfully managed to check for an update (by comparing XML files) and downloading the zip file from the FTP server into a temporary folder. However once I started copying the files into the main folder, application suddenly crashed becuase all the dll's I have tried to copy were already in use.
I came with two approaches that are possible:
1) rename all the files under the main folder to: originalname.dll.bak (append .bak to the end of their name). Then copy original files and restart application. Upon opening new instance (updated exe file), the very first thing we do is that we erase old files ending with .bak. One problem with this approach is, that I can easily rename currently running process to include .bak, yet I am not sure if I can do the same with the dll files (have not implemented this solution yet)
2) Create an external app (e.g. console app), which will be executed from the main application whcih will handle the update process. Upon opening this external updater, my main app will immediately close so that we can assure that copying of the new files will be without a problem.
I have not done any of this before therefore any comments & suggestions will be more than welcome. Also shall shall there be any better way how to handle the update process, I would be more than happy to implement it.
This is probably a stupid mistake of me.. but I can't seem to understand it.
I've created a new, empty C# Windows Forms application.
I added a Database (Based on a dataset) and have the file stored in my solution explorer.
I've added a table Test with column Name.
I add a record using new SqlCeCommand("insert into Test values('Name')", new SqlCeConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString)).ExecuteNonQuery();
However, I've even tried retrieving the same data and it all works perfectly.
But when I stop my project, and rebuild it.. all data is gone again?
Is there a way to fix this, or will this fix itself when I'll start using this project for what it is intended (Without the 500 rebuilds a day?)
Your database file is listed in the project with this property
Copy to destination directory = Copy Always
If this is true then every time you restart the project a fresh (empty) copy of the database file is copied from the project directory to the output directory (BIN\DEBUG or BIN\RELEASE) overwriting the database file used in the previous run. You could avoid this changing the property to Copy Never or Copy if newer
The answer given by steve keeps copying the database over the existing one, which results in removing all data.
I've managed to fix this by putting "Copy Always" on, then in the explorer move the database to a different location and add it to the project. This way the database will never be overwritten and can be used in the program!
(However, this will probably raise a issue if/when I publish the project to another computer)
I want someone to just be able to fire up my solution, and in the Program have it run and just put this csv at the root of the project for example so that it just picks it up in my method that's gonna read this csv file.
File.ReadLines(filePath).Select(a => a.Split(';'));
Problem is, not sure how to get this so that if someone copies my solution to their c drive, what this filepath should look like..I want them to be able to fire this solution up, run the console app, and since this file is already in the same directory as my project, just want to basically hard code the filename via constant and not worry about ok, where is this file..it's always gonna be here after they copy it for testing purposes.
So what should I do, include the .csv in my .net project then just make the constant "filename.csv"? I tried that, does not work.
I end up with this which fails:
File.ReadLines("someFile.csv").Select(a => a.Split(';'));
and I've included that file in my project...the main console project where the program is running from.
here's my solution structure
SomeTest (.NET solution and it's the root solution folder)
SomeTest (console project)
Constants.cs
SomeTest.BL
SomeTest.DL
filename.csv
I've moved the actual csv to my DL as I'm using it as the test data source.
So when they copy my SomeTest solution folder down to their c drive, wherever they put it, I need that constant to read C:\\root path to wherever they copied SomeTest folder to\\SomeTest.DL\\filename.csv see what I mean? I need to hard code the SomeTest.DL after the root path..but I just can't get the root path, in my case C:\www and grab that part and then I'll append for example the \SomeTest.DL\filename.csv" string to it.
I think the safest option is to add the csv file to your project and set its BuildAction to None and set Copy To Output Directory to copy.
Then users can always access using File.ReadLines("MyDataCsv.csv"), plus you can view/edit the csv from the Visual Studio IDE which I assume the other programmers will want.
I'm trying to make an uninstaller.
I basically need to be able to remove a directory in the program files that contains the uninstaller.
I was thinking to have the uninstaller create a copy of itself to the temp folder,
then have the uninstaller running from the program folder open the uninstaller in temp and close itself where it continues the uninstall.
Problem is, how do I delete the uninstaller in the temp folder...
Check out: https://www.catch22.net/tuts/win32/self-deleting-executables
He has multiple solutions - but mostly aimed at C++ code.
I am currently trying to implement the "DELETE_ON_CLOSE" method in C#.
A comment to all the nay-sayers: MSI does not solve this problem in all cases. In my case, my application needs to install to a network folder, where any network user can run the app. It also needs to support upgrades and uninstalls from any network workstation - not necessarily the same workstation that installed the app. This means I cannot register an Uninstaller into the Add/Remove Programs list on the local machine. I must create an Uninstall.exe that is dropped into the install folder. MSI does not support that, so I have to write my own.
Even though I agree with everyone saying you shouldn't do that, what you can do is:
Have your program create an executable (and config file) in the temporary folder of the OS it's working on.
Have your program start it as an independent process, then exit.
That executable then calls back the actual setup stuff.
Once the setup is done, the temporary executable can delete the setup files.
Since the only trace of your program is now in the temp folder, it will eventually get cleared automatically.
I have a console application, that when I run (from within vs.net) it takes a while as it is a long running process.
I want to continue coding in vs.net, and maybe even spawn multiple instances of the console application.
How to best deploy this on my desktop cmputer?
Is this a good approach:
create a folder:
/myConsole/
then subfolders for each instance.
Do I just grab all fines in the /debug folder or are there other dependancies?
If you run without attaching the debugger you can continue coding while the program runs.
Debug Menu | Start without debugging, or Ctrl+F5
Note: using this method, you can compile the modified code, but cannot run it since the .exe output file will be in use. I'm not sure if that's a problem for you.
One way I've done it before is to create a release build from VS. Then open as many command prompts as you need on the release folder and then run it from there. Then I change back to debug build and continue coding. This lets me run the separate instances and also debug if need be and it's all as simple as changing the type of build in VS.
You should consider executing your code through system tests in a unit test console like the one that Resharper offers. It does shadow copying for you and allows you to nicely run multiple sessions, start/abort them etc. I think this is far more clean and flexible than firing up test apps all over the shop.
If you dont need to have the debbuger attach, what about just going to your /bin folder and double clinking on the exe, as many times as instances you want open?
If you DO need to have the debugger attached.. then the only way I can think about it is to have multiple instances of VS running, each with the debugging on :S
In general, there aren't any dependencies outside of your bin\debug directory. If you want to test this long-running program while you're still coding and re-compiling, you'll want to copy the contents of the bin\debug directory somewhere else, and run it from there.
Whether or not you can run separate instances from the same directory depends on how the program deals with output files or other resources. If the name of any output file is hard coded, then you'll have to run multiple instances from separate directories. If you can specify files on the command line, then you can run as many instances as you like from within a single directory.
You should be able to copy your console application into a separate folder. This would be all the files in the build folder. Then, you can just run it like any other exe. If you are not sharing settings / data in the application folder, you can run the application as many times as you like. Windows is quite happy to run a number of instances of the same exe.
If you wanted to automate, you could copy the application out of the build folder in a build event...