I want to create a window based application in C# so that we can run it without installing the application into each and every system.
It need to connect that application through database as well.
I want to create this application so that it can be run directly through pendrive and can write into database as well.
I know how to work with database though window application but with installer only.
I have created many window application
but all runs on client machine after
Installing the deployed setup. But now
i want client need not install the
setup deployed. He can use my
application by directly clicking my
executable file
There is nothing in Windows that requires an application to be installed. That said, installation is intended to:
Make things more simple for the end user.
Setup the registry, usually for path information and uninstall information.
Initialize any initial information the software may need before it's first run.
Simply avoiding using the registry and saving files locally to your application is usually enough to make your application portable.
That said, as long as you allow the user to select a database location within your software, you should be fine. Saving the information on the pen-drive, in an .ini file for instance, would allow each computer you plug into to read these same settings.
If you expect each computer to have a difference connection string to the database, you could save your settings to the %appdata% directory. When the user plugs the pendrive back in later, his settings will still be there, and no other user will see these same settings.
The downside to the second approach, however, is that the user has no way to "uninstall" and recover the space written to %appdata% automatically. However, for most private business applications, this isn't much of a concern.
Edit: If your real question here is how to distribute an application without an installer, simply build the Release version of your application, and look in /bin/Release/ within your project. Copy these files to another location, remove any debug or unneeded files, and make sure you have all your dependencies in order.
If you just want to connect to a database, you can do that in the EXE without any kind of installer needed. How that is done would depend on which database it is, and how you are connecting to it, but generally the item that requires encoding in the EXE (or in an outboard XML file which the EXE can read) is a connection string. This connection string is probably what the installer is managing.
A good tutorial on building your first Windows application in C# can be found here:
http://msdn.microsoft.com/en-us/library/360kwx3z.aspx
If you don't know where and how to start window form application or how to connect to database or so, there are plenty tutorials and you can Google for it very easily ;)
Here are few examples:
GUI related:
Tutorial: Working with Windows Forms
- Part I
GUI Windows Forms « C# / CSharp Tutorial
Windows Forms
tutorial with C#
Databases related:
Creating a database connection
Simplest form of installation; use an if/else; when application start, it would check for some registry key (lets say, installation=done), if the value of registery key is="done", then run the else part, which means run the app. If its "notdone", then setup all initial settings and then run the app. A pseudo will go as follows:
if(HasValidRegistryKeys()) //Check if initial settings are already there
{
Runnable=true;
}
else
{
//Not installed, lets setup app settings
//Assume that the application is running for the first time.
try
{
SetupRegistry(); //Set installation=done
SetupDatabase();
//Setup more things.
Runnable=true;
}
catch()
{Runnable=false;}
}
//Run the app
if(Runnable)
{
RunApp();
}
else
{
MessageBox.Show("Some error");
}
Related
I am working with the solution which has WPF window, which is working with SQLLite database and Windows Service, which uses the database data. Also, WPF window has used an installer and uninstaller for windows service.
The main idea of this program is to control access/deny to all programs. I have all scripts finished, but I have to create installer and uninstaller for this solution, and uninstaller has to be protected by the password ( this program has the same idea as parent control programs, so some users don`t have to be able to use/delete the program) Maybe there is some other solution to protect it without creating installer and uninstaller?
I had the idea that use was able to delete all files, but windows service will be still working because it was installed by the WPF window before. It seems to be a good solution, but in this case, SQLLite database will be removed.
Have the windows service and/or the wpf app create/copy the database in runtime and put it in another directory (e.g. LocalAppData). This way, when the user decides to uninstall the programs, their local database will not be removed from their machines.
I’m working on a windows app composed of two parts:
An agent, running in the background.
A main application with a window to start/stop the agent and configure it.
What I understand is that I should use a “windows service” for the agent.
But I’m not sure how this is supposed to be packaged? (Can I have these two parts in the same .exe?)
And how the agent and the main application can communicate (should I use a shared file? Can my agent have a private folder to work in?)
I’m looking for some architecture advices basically
Running the agent as a service is probably the best way to go. It'll run without anyone needing to be logged in to run it, and Windows provides extensive monitoring support for services. You can use the sc command to install, start and stop a service, and it even supports controlling services on other machines if you've got the appropriate permissions.
In order to have your gui communicate with it you could look at using WCF. It will allow you to define your interactions with the service as C# classes and will save you having to worry about checking shared directories or looking into a shared file etc. This approach will also make it easy to support multiple clients at the same time, whilst something like a shared folder approach will make this difficult.
You will need to have to separate .exe files, one for the service and one for the windows application. You can package these are two separate MSIs within Visual Studio, the benefit here is that if you need to move the service (for whatever reason) you are not then also packaging up the Windows App and leaving it where ever you install the service.
There are different ways you can have them communicate without getting massively complex. you could read from a text file, as you've suggested, but this could cause locking problems. When I've had to do similar I created a simple database in SQL (or any brand of database you wish), and have the Windows App insert / update configuration options to a table, and the service then reads the table to get its settings.
I'm working on a WPF application right now in C#, and I need to be able to save some images. These images need to be saved into a directory that the user that's currently logged in doesn't have access to without some administrative privileges (essentially, to control the security on what images are being saved to that directory).
How can I set up such security permissions? Is there some directory that I can add subdirectories to with these images inside?
Normally, I would try to post some code in example to what I have. I'm not entirely sure where to begin with this problem, though.
As Andrew already told in his comment you should really best start with a service. This will run under another account (normally System, but you can change this within the control panel). To start with this a service is in the first step nothing more than any other normal process. So to get a connection between the user application and the service you can use any inter-process communication as you like.
The only difference between a normal application and a service is that the service will be started and managed through the service manager and thous needs to derive from ServiceBase. Also maybe this Walkthrough might help you to start.
Default context for all non-user programs is system which it available to you via service programming and you are not familiar with it. A hack would be logging into another account (i.e administrator) and run the program in that context which is not possible on all windows versions and I believe doesn't worth the resources it cost and also is a security risk.
Another solution would be encrypt your application data and store it somewhere.
I have a web app and want to transfer data from client's machines to us every day. Assume there is a common API on every client machine to extract data from. To make this work, I have to create:
An API to receive data from clients - using WCF, seems ok at this point
An application that's installed on client machines
The client app needs to store info from the user (eg username/password to access our API - encrypted with DPAPI). The app needs to run daily (probably with a random Sleep() command so our API isn't overloaded all at once). It also needs to be easy to install.
I've created a console app which talks with the client API and our own API. I've used Visual Studio's Settings.settings with a user scope to save the persistent settings - if parameters are provided then it stores these settings, if no parameters it uses the stored settings.
How can I make this usable for the end user? I'm thinking a separate installer/configuration program that installs the exe file (and its dependencies) and asks the user to enter the settings to be stored (which can also be read by the client app). It would have to set up the scheduled task and also offer the ability to change the configuration (the stored shared variables).
Hoping someone can help architect this solution?
Thanks so much!
I think that your idea about an installer is correct since you will most likely have dependencies or prequisites to install.
However, rather than building the settings logic into the installer, I would recommend that you build a UI for this in your application so that the user can adjust it post-installation if needed.
For example, if the user changes their password, in your current design, the user will have to uninstall and reinstall the app. Also, if the scheduled time is incompatible with some other operations on their machine, then they will need to adjust the time without uninstalling and reinstalling.
You could build the UI and API interface into a single application: just change the behavior (runtime or configuration) with a command line switch (for example, only use a /runtime command line switch for the scheduled task).
I have developed a small application with SQL SERVER back end and I also make an installer for the application with Indigo Rose Setup factory 8.0. What I need is I want to automatically create the database back end with specific user account during the installation of the application.
Before the installer a user is asked to install either SQL server or SQL express as prerequisite, when the database is installed the installation of the software continues. I tried to do using SQL script but I don’t how to do it before installation on the installer software. I though also to embed the database creation program in the main application and it will execute on the user need upon the completion of the installation but I have never tried it before whether it works or not.
Incase if it need I developed the system using C# with SQL SERVER 2005 backend.
So would you please give me some answer to tackle the problem?
Thank you
The simplest way would be to have the installer call sqlcmd.exe to run a sql script. To call that, you will need to know the data source (location) of the sql instance. You will need to get that from the user. For example, machinename, machinename\instancename or typically sqlexpress is machinename\SQLExpress.
http://msdn.microsoft.com/en-us/library/ms165702.aspx
You can also side step the pre-req and install sqlexpress for your customer. There's a cmdline to install it:
http://msdn.microsoft.com/en-us/library/ms144259.aspx
Another option with no sql dependencies is to write your own custom action (command line/API), parse between the GO statements in the script and execute with ADO.net.
Another option outside of setup is to separate setup and configuration. Setup only lays down bits and the database is created at runtime via a configuration phase of the runtime of the product. This has many benefits including being able to update your bits (either with a patch or automatically) after the setup phase and before the configuration phase. You can also give a better interactive experience and handle issues at runtime - with setup, your choices are to fail setup and roll it back which is a bad experience.
Hope that helps.
Bryan already gave you good advice. My recommendation would be to have the application itself be capable of deploying the database by running the deployment script(s). You can use a library like dbutilscmd that parses the .sql scripts and executes the batches from inside the application. I would also advise to have your scripts be capable of upgrading the database, not just deploy it. This will be very handy when you release v. 2.0 of the application. See Version Control and your Database.
One thing to consider is that often the initial database deployment requires an elevated privilege context. There are some options, see Teach Your Apps To Play Nicely With Windows Vista User Account Control.