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.
Related
I have seen there are many technologies out there that make auto updating easy for the user (such as winsparkle). The problem we have is we want to be able to auto update our desktop (c#/c++) app without prompting.
If users have the ability to NOT update it makes our lives hell (10,000+ installs all need to be updated about once a month).
We currently install our application via WIX and it reinstalling a new version completely overwrites what was there before. This works fine but we'd love to not even have to run the new installer, thus the idea of auto updating.
I've looked at clickonce but since our app is both a tray icon/windows forms app and a Windows Service it appears installing a service via ClickOnce is somewhat unfeasible.
Any suggestions?
To do this update behavior you need two things:
1) An updater application which checks for updates regularly. If an update is found it should install it automatically. Most commercial setup authoring tools include good updater applications. You can try writing an updater yourself, but it's not as easy as it sounds.
2) Per-user installations for each of your product versions. A per-user installation writes data only in the user profile folder (AppData, Roaming folder etc.) and HKEY_CURRENT_USER. No Program Files or HKEY_LOCAL_MACHINE.
Per-user installations are required so you can perform the upgrade silently. If the installation is per machine, newer Windows version will show the elevation prompt and the user won't know what's happening.
The Updater
Some updaters use services. For automated updates this isn't a real solution because service installation needs Administrator privileges. So your install process and subsequent updates would show elevation prompts.
Another approach is to use a per-user Updater application. It doesn't require any elevation and it can be installed in the application folder. This type of updater can run either as a scheduled task or from within your application (execute it when your application starts).
In both scenarios you need to consider that the Updater may need to update itself. So the process which performs the update must be a temporary process (for example a temporary copy of the updater application). It also should run without elevation. This is why a service is not such a good idea. It would need to stop itself before the update, use a temporary process which handles the update and start again when finished.
Here's what I ended up doing for some applications that I manage, and that are written in C#.
I distribute an installer based on InnoSetup to deploy the files on the user system, and the application stores information version in the registry.
The application has a mechanism that checks at startup for available updates, and prompts the user. This system is based on a JSON manifest that contains a basic structure such as the following:
{
"releases": [
{
"CommitDate": "2020-09-05",
"Version": "0.1.0.0",
"VersionString": "0.1.0+19",
"SHA": "4ff750da44b41e569daf3c62f4495a8ee2b25f08",
"InstallerMd5Sum": "805497b5c13ee070b7465bb32689e0dd"
},
{
"CommitDate": "2020-09-07",
"Version": "0.1.0.0",
"VersionString": "0.1.0+22",
"SHA": "a04ec929b21230ba0e2577617713d10b106266e9",
"InstallerMd5Sum": "805497b5c13ee070b7465bb32689e0dd"
}
]}}
The application downloads that file and compares its local information with the latest entry in the file.
If the latest entry is more recent (based on things like commit date), it retrieves the installer from the distribution server, checks for integrity, and run the installer.
The installer takes care of updating the entries in the registry with the latest information.
Now, there are three angles to your question I believe.
The first one is whether a modularity is possible so that you don't end up replacing everything and can provide delta installers, the second is whether you can use a technology that knows how to deal with updates (which I believe MSI knows how to do). Finally, the third angle is whether or not you have a way for users to rollback in case the latest version has issue with their system or whatever your application is for.
TL;DR: I have a service, a gui, and a tray icon. I want to know how to get the tray icon to run on user login/start-up and be able to stop the service and start the gui
Some Background Info:
I have a windows service I've made that uses a xml file to collect
files from other computers on my network and store them on the local
pc (running the service). the xml has some structures called
'profiles' which have info like FileDestination, LocationToTakeFrom,
FileTypeToTake, and IsProfileActive...
The service basically takes all the active profiles and every hour
scans the location for files created within a 1hr window of the
current date/time on local PC.
My GUI allows the user to make profiles / modify profiles, as
well as determine which profile(s) should be active for collection. I
dont want this gui running at all times, so I plan to have a
systemTrayIcon to allow this GUI to be opened and shutdown.
I'm using Visual Studio 2010 .NET 4.0 everything is in C#, I have 1 solution with separate projects(gui and service)
I'm wondering about the following things as far as the System Tray Icon goes:
1) how do I have the icon start on user login (note that this will be distributed via an installer, not just my personal use. so It has to be done via code)
2) Stop a service via sysTrayIcon
3) where to place the SysTrayIcon... do I make a 3rd project? add it in the GUI project? not quite sure here.
4) if SysTrayIcon IS in a seperate project how can I have it create instances of the GUI?
ie how can I start the GUI application from code in a different project
the project requirements are:
-upon installation the GUI must start, after that the Gui should only be accessed through the tray icon.
-user should be able to stop the service any time via system tray icon
Start the client
There are plenty of ways to start an application on Login under Windows. Just grab SysInternals AutoRuns to get an idea. The obvious ones are (a) the good ol' Startup group and (b) one of the
\SOFTWARE\Microsoft\Windows\CurrentVersion\Run*
keys under HKCU and/or HKLM. That's the typical task of an setup utility, which makes sense since you have to install the service anyway. To do it in code:
Registry: Open the reg key, add the entry, close the reg key.
Startup: determine the value of CSIDL_STARTUP or CSIDL_COMMON_STARTUP using SHGetFolderPath, then create a Shell Link in that folder.
Service communication & control
The GUI part implements the TrayIcon and communicates through some channnel with your service. Again, there are plenty of possibilities how to do this, like disk files or memory mapped files, named pipes, even sockets. It would be too broad to list all the ways here, so I'd suggest to decide for one way and ask again if you have specific questions on that one.
To stop your service from code, use the ControlService() function and pass SERVICE_CONTROL_STOP as the dwControl parameter. To start a service, there's another function named (big surprise) StartService() to achieve that. Note that you may need to start an elevated copy of your app to control services. A quick & dirty way is to simply launch net start/stop MyService elevated with the necessary args.
I have a simple console application written in .NET. I need to make an installer for the console application and put it in the server directory. This can be achieved by using the Setup Project in MS Visual Studio. I also want the ability that whenever I open the app it checks for a new version. If the new version exists then it installs it. Any recommendations on how to achieve this in .NET?
ClickOnce handles versioning for you. Simply publish new versions to the same place as previous versions, and when the user starts the app they will receive notice of the new version. That's part of the whole point of ClickOnce. The downside is, you lose control over the location of your application in the user's filesystem (for a simple console app like yours, that's probably not a huge deal, but I'll leave that decision to you). We've also had difficulty with certificates; if you sign your ClickOnce manifests (strongly recommended) you have to keep exactly the same certificate, strongly identifiable from a major CA, to keep the ClickOnce process strictly "click once".
Pretty much the only other way to handle versioning is to implement some web service that will report the most current version, and have your app call that service on startup to notify the user of upgrades. The upside is that your users still control where the app goes, and you can control where the app is published (if the next version needs to go on a different server, no problem; just point the user there using some information returned by the web service). The downside is more work for you to develop and deploy.
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");
}
i have designed an application which validates users against online database and then allow users to work, after authentication it shows desktop, it loads on startup.
i would like to start my login application at windows start up, i have added my login application path to registry it is started well with windows. but it has one issue
first windows desktop appears few seconds and then my login application loaded
i would like to show my application before windows desktop
or
any other way to use windows login to validate user against online server database and then allow users to work.
If you don't want the desktop to show at all you can run your application as the Windows Shell.
You use this registry key
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="C:\\WINDOWS\\explorer.exe"
The other solution is to use XP Embedded Standard so you can totally customise the Windows experience. Takes a lot more work than the simple shell replacement though, but much more robust
You could replace the shell as above, then have your application launch explorer.exe when you were ready to have the start menu and taskbar show up...