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.
Related
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.
I decided to widen my horizon and use C# (the free version) for a small program.
The program opens a mysql table and shows it's contents in a listview. I compile and run it on my developer machine and everything works fine. Then move it to my girlfriends computer. The application starts and the window appears but the list is empty.
Is there any limitation on the free version that prevents connection if it's running on another machine? It is the release compiled exe I'm trying to run.
There is no restriction that I know of. How are you handling exceptions? It's for more likely the environments don't match meaning you don't have MySQL or connections string isn't correct for the other computer.
If you're catching exceptions and suppressing the errors then you could easily be over looking exceptions with regard to the connection.
Ok, this is a somewhat odd question, but I found a problem similar to these:
Debugged Program Window Won't Close
Unable to kill instances of cmd.exe on Win XP
How to close an "orphaned" console window that was opened from within visual studio?
I've found this problem recently on a production environment, oddly enough this machine did not have VS installed, and I was not debugging, but the behavior was exactly the same. The only thing I've found that really worked was using PSKill (http://technet.microsoft.com/en-us/sysinternals/bb896683) to close csrss.exe (which controls all console windows). This, obviously created a crash, but I was able to reboot the machine. I found this particularly helpful, provided such machine was not physically accessible.
The box details are:
Pentium 4, 1GB RAM, Windows XP SP2 (mind you, this is not my ideal setup, but not for me to decide :P)
I would, however, like to know if there is a way to prevent this from happening again.
I want to emphasize, there is NO VS installed on this particular machine, and the program running is not a Debug build, but a Release one. I did try Microsoft's KB 982551 hotfix but to no avail.
The particulars for the app are like this: It opens and connects to another process via named pipes, and then it will close if communication is interrupted or you close the console window via the X button or typing 'q'. Apparently the named pipe went down somewhere along the way, and the app stayed alive (which does not happen in any other cases, just this one).
Can you think of a way of tracing/reproducing this behavior in a more easily controlled environment?
I'll be happy to post any part of the code if you ask for it, I'm not doing it right now because there are like 5 different files that do the full job.
Edit: Oh, I forgot to tell you, the target machine does not have KB 978037, just in case you were wondering.
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.
Is it possible to rise a cmd.exe processes from the silent background mode to the visible foreground so I can LOOK at them?
Problem Background:
I'm using VS2008 working with a very large solution containing C#, C++, and Fortran. Occasionally (a few times a day) when building my project the build hangs and does not allow me to do anything in VS (resulting in the need to kill the process). I have checked the output box, and there appears to be nothing helpful there.
Possible Cause:
I am thinking that maybe one of the cmd.exe windows that are spawned in the background may be waiting for some form of input, but to investigate I need to see those windows.
Search for Other Causes/Solutions:
If not this, is there a way to try to check and see if there is something else going on? Is this a problem anyone else is having. (Note: killing VS and reloading often fixes the problem first try, and the build process takes less than 15 seconds.)
If stopping and restart fixes the problem, I guess it's not an input problem.
For example when my build project halts, it's always the VB6 project or SVN that are upset. (strangely the VS projects always work fine).
Once one of these halt, they halt until they are fixed. Thus for the VB projects run and work-out what the model dialogue is saying and fix it. or on SVN it usually need a clean-up run on the directory.
The intermittent nature suggests some sort of timing issue, like a file been lock open etc.
You could attach another copy of visual studio to the cmd.exe and see where it's at. Not sure if you can get symbols for it, so it might be fun to diagnose.