I have a solution with a Web Application, Console Application (and Windows Service, but that's probably for another question).
Publishing and keeping the Web Application up-to-date is easy. I simply right-click Publish to publish initially or update the live version.
Currently to "publish" or update a console application I copy the release exe and files over to the live machine. In this way I can use the task manager to run the exe in the copied location.
This smacks of bad practice to me. The problem with doing a right-click, Publish on the console app is there's no easy way for the task scheduler to launch the exe. Additionally i'm not sure what would happen when it came to updating the application. Would the "An update is available" screen just sit there waiting for a user to click ok??
What is the best way of easily publishing and keeping a console application up to date?
Ideally something I only have to do from Visual Studio (2008). I'll need to be able to set up task scheduler and then forget about it (no need to do anything with task scheduler or click through anything when updating).
Automatic deploy of applications partly sounds like Continuous Integration.
You may not be interested in the TDD parts, so you can just focus on the tools that allow you to grab code from your repository (SVN for example), build it and deploy it automatically.
Personally, and based on personal experience, I would do this for backstage environments only, for production I would stick to copying exes manually (and keeping backups, of course!)
Personally for these server side executables I just copy the exes. If you're updating them a lot and you want to ensure that you don't put them in the wrong folder or miss a file you could write a .bat script to do the copying for you so that you can just double click on it.
To be honest if you're deploying a new program so often that this is a major issue for you then I'd say you have a different problem. You shouldn't be making changes to a production app all that often. There might be something that's currently code driven that ought to be data driven such that you can make modifications that you need to your program by modifying your database, config files, etc. and not the code of the program.
Related
I need to develop a project using Visual Studio. The project will run constantly in the background, checking a file path. When the image is uploaded to the file path, the application will display the uploaded image as a pop-up on the computer screen. The application will not be triggered by a user. It will constantly run in the Background, checking the file path. Which project template should I use for this? I hope I was able to explain.
I thought of writing windows service. Because it can run in the background. But I couldn't open a picture with it
I see you're a new contributor, so it would be better if you posted a bit more context of what you have already tried. For instance, providing a minimal reproducible example. I ask you this because the way to write Windows Services or Console Applications in .Net Framework and .Net Core (and subsequent) are different. How to ask a question?
That being said, a windows service, by concept, does not have UI and is not allowed to have one. They're designed precisely to only run on the background, without user interaction (at least since Windows Vista).
These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface.
From Microsoft Docs
So it seems that you need to either write your application as a different kind (for example), or create a secondary application that somehow communicates with your windows service. The decision would be up to you based on your requirements and/or possible limitations.
There are some possible alternatives in this possibly related question as well.
I'm sure this has been asked and answered, and I apologize for that, but I'm not really even sure what I'm looking for or need to do. I'm an electrical engineer that can play with programming, but when it comes to servers and remote stuff, I get really lost.
Anyway, here's the stick. I'll try to be specific.
I'm not sure this part matters, but I'll try to explain for clarity's sake. We are developing a machine. This machine is run by an IPC. The IPC is basically a PLC that has embedded Windows 7, and the IPC itself is programmed with Structured Text which is written in VS2013 (doesn't work on newer versions). In order to 'activate' the programming and parameters that we set in VS2013, this computer must be connected to the machine with an ethernet cable. I can also remote in to manually control the machine from this computer.
For an operator to control the machine in general, a CS major wrote a program that we call the HMI, or Human Machine Interface. I access and update the code for this, which is written in C#, through VS2017. The project is set up as a solution, and in order to 'activate' this programming after making changes, I just build the solution and copy the dll file over to the machine, through the remote interface. On that machine, we just click an executable that starts the IPC and then I'm guessing the IPC has been linked to the HMI program, because that opens shortly after that.
Ok, now, I'm trying to implement a new feature into this HMI and I'm running into some unknown error. In order to correct this with any program I've written in the past, I would normally set a breakpoint and/or run the debugger and go through step by step until it breaks. However, since this program has to run in tandem with the IPC, which it passes values to and receives output from, it's more complicated than that.
The CS person I mentioned no longer works here, but his note says that the debugger can be run as long as I'm connected with the ethernet cord I mentioned. When I try, though, I get "A project with an Output type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project."
Now, from googling, I've found and tried to set the solution as a startup project, but it didn't seem like anything happened when I selected that, and furthermore, the error persists. I'm guessing that I need to do the latter, which is to 'add an executable project to the solution and set that as the startup project'... but I really don't know what that means, at all.
Do I 'add an existing project' (under File)? If so, would that be the project/solution from VS2013?
Or do I somehow need to add the executable that we click on the machine?
I sound like an idiot, I know, and that's because I am when it comes to this stuff, haha. It may be too complex for anyone to even attempt to answer, or so simple that I'm way overthinking it. I have no idea at this point, and I'm desperate.
That said, I would really appreciate if someone had any idea. Regardless, thank you for your time.
You can debug an executing process by using Visual Studio's Attach to process tool which is in debug menu. This will attach your source code to an executing process as long as the code and process code match.
I am working in VisualStudio 2010 SP1 on an application server system written in C#. (Yes this is a legacy application.) The system is a large multi-threaded server application that provides a large SOAP API along with newer REST APIs for other portions of the system.
For a long time I have noticed that occasionally when starting the system in debug mode both the server and VisualStudio would stall. Neither UI would respond and calls to the server APIs would block. This situation could be recovered from only by halting the server using Task Manager, after which VisualStudio would complain with an error.
Recently this problem became persistent, that is it happens every time. The lock up occurs at various times, that is I have not been able to identify a specific time when the system locks up, it may (often) happen as soon as the server is started, other times it may take a minute or so, but always shortly after startup, both VisualStudio and the server lock up.
If I try to do something in the VisualStudio UI, e.g. pressing the Pause button, I will get the "Microsoft Visual Studio Delay Notification" icon in the notifications section of the Windows task bar.
I have done some investigation on the web and have tried the following unsuccessfully:
Clean rebuild
Removing all build products from the directory structure
Doing a clean checkout in a new directory structure
resetiis
Removing the .suo files
Resetting the VisualStudio settings
I have also tried creating both mini & full dumps of both the application and devenv, but I have not been able to understand them well enough to find any issue.
What would you do to try to identify the issue?
The solution to my issue turned out to be working on the program using VS2015. This is not a wonderful solution since we still build in VS2010, but it at least allowed me to proceed. We are not sure exactly what caused the issue.
I have a small application which is a single executable. For context, this is deployed to Thin Client computers and runs automatically at boot. Users do not have the rights to close this application.
However, I need the application to be easy to update. I can't write my software to do any kind of auto-update routine, because these stations often have a write-blocker* which must be disabled beforehand.
The simplest solution as an administrator is to copy the new EXE over the old using the various tools provided with the Thin Client, or Group Policy / scripting where required. The update doesn't have to be instantly effective - the next reboot is fine.
The problem with this is that, of course, the executable is in use and can't be overwritten. What's the best way to allow this to happen? Load the software completely into memory and run from there? Do some kind of routine which copies the exe to a temporary folder and then executes it with a command line switch so it doesn't endlessly loop?
*This may have caused some confusion. These are Windows XP / Windows 7 Embedded machines. For the most part they work like normal computers, except file system writes are transparently redirected to a cache drive. On a reboot, all changes are completely reverted. A normal script to update the machine would go something like:
Disable Write Blocker
Reboot Machine
Copy Files
Reboot Machine
Enable Write Blocker
Reboot Machine
However, my application will autostart after every reboot as there's no mechanism to inform it. As such, when the scripts get run the executable is still in use.
You might be able to use Windows' MoveFileEx with the DelayUntilReboot option.
To do this from C#, see this answer which shows how to set up the call to the Windows API.
Note: I think the call needs administrator privileges.
You could make of use of something called Shadow copying assemblies. Search the net, you'll find lots of examples (also on SO and Codeproject).
Obviously the application can only update if your write protection is disabled. Are you using FBWF or EWF? You might even exclude the application folder from write protection.
My program has a handful of settings that need to be established before it can operate correctly. I would like the user to be shown a setup wizard either at first run or at install that has them set everything up to their needs. Right now my program does not use an installer, it just runs from its exe file. The program does offer the option to change these settings when it is running, however I want the user to set the settings first before the program runs. My options seem to be:
Use a setup wizard (either my own or one created such as this link.)
Make the program use an MSI and install. Several have pointed out that an MSI will allow for a program set up while installing which would satisfy the need I have.
As an MSI option sounds like it is the norm for programs I should perhaps learn about those. But I am still curious for other peoples input on this particular problem. For those who are going to recommend the MSI solution, I'm new to this particular aspect of programming, any recommended links are greatly appreciated.
I think it really depends on what your application deployment does. If it simply copies some files and registry entries an MSI will handle most of your needs, including upgrades. Here is a similar discussion which may help you: What is the best SIMPLE replacement for VS Setup-project Installer for WinXP + WPF + .NET 4.0?
If your deployment process involves custom and/or complex tasks, a customized wizard is better because it gives you more control. MSI packages are very limited when it comes to customization.
We do something similar:
Whenever the application is launched, we check the settings storage (usually a database) and if anything needs to be set, we launch the setup wizard.
If the user cancels the setup for some reason, the application is terminated, meaning that the user can't proceed to the main application until the initial configuration is complete.
Having spent an inordinate amount of time configuring (or attempting to configure) installers (Installshield, Installaware, etc), I can promise you that this is the most effective, efficient way to accomplish your goal.
There are some things that you should (and in some cases, have) to do in the installers, but from your description, they don't apply to your situation.