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...
Related
I have created a Console Application where I've added Microsoft.AnalysisServices dll. I want this App to be Scheduled for every 30 minutes.
I've Published the Application but when I give setup.exe path in Windows Task Scheduler, the task not runs
When I give the applicationname.exe path from the bin/Debug Folder, the application runs
reference: https://www.c-sharpcorner.com/UploadFile/manas1/console-application-using-windows-scheduler/
but I don't want to carry the project folder to the Production server, I need a single exe/setup file
I have also tried copying application.exe file from bin folder on desktop but it throws exception 'cannot find Microsoft.AnalysisServices', here is the Screen shot:
Please Help
For a (simple) console application, the easiest solution is to use what Microsoft propagated right from the start of .Net: "xcopy deployment".
Depending on your build target (Debug or Release) take everything from the [project dir]\bin\Debug or [project dir]\bin\Release and copy it to a application folder of your choice.
In your Scheduled Task, reference the executable in this application folder.
You can streamline your deployment by adding an automated copy task as a Post-Build task to your project configuration.
You need to copy the whole output folder (publish artifact). You can omit things like the pdb files or xml documentations... You can also use tools like ILMerge to merge dependencies like the Analysis dll into one file, if you really need to.
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 created a console app that I want to use in a scheduled package in SSIS. In the app, I'm connecting to the database to get email addresses and sending emails to that list. When I put the .exe on the server it won't work, but when I put the whole folder over, it works fine. I'm assuming it needs the app.config.
What's the best way to deploy the exe to the server? Should I publish the console app first, or just build it and take the exe and the app.config (not sure if that's possible)?
If your .exe needs the app.config either copy the app.config over as well, or alter the program so that whatever relies on the app.config...doesn't...so you don't need to copy the app.config. The second may or may not be a viable option, since we don't know what in your program uses the app.config.
Seems like a fairly simple choice to me. What else were you expecting to hear?
Copying whole Bin folder is perfectly valid way of deploying files (sometimes called x-copy deployment).
There could be other files in Bin folder (i.e. referenced assemblies that you marked as "copy" in the project).
You can build more formal install package, but it most likely overkill for simple scenarios.
I've never burnt a visual studio program to a CD before. I've made a setup project with all my program files, and it works fine. Do I simply need to burn the following installer files onto the CD and give it to someone?
The installer is a folder containing:
-DotNetFX35 (Folder): Contains .net requirements for my program.
-WIndowsInstaller3_1 (Folder): WindowsInstaller-KB893803-v2-x86.exe
-setup.exe
-My Installer.msi
Sorry for the seemingly easy question. I'm double checking as I have one CD and an impatient employer.
Thanks!
You will need to add an autorun.inf if you want autorun to work. Put the contents of the install folder at the root of the disk, create a simple text file called "autorun.inf" at the root of the disk and add the following contents:
[autorun]
open=setup.exe
This will instruct the operating system to run setup.exe when the disk has inserted (and consented to it).
There are other tricks you can do with autorun.inf too. As many have mentioned in the comments, the best way to test this is by creating an ISO and testing it, or buying a stack of blank disks. They are pretty cheap these days.
If you don't care about auto run, then you can put anything on the disk itself, it's just content, the user would just need to go into the contents himself and click setup.
I have a .NET Windows application that needs to call another .NET executable. I want to distribute this other exe as part of the main project, and was wondering what is the best way of implementing this. We don't want to take the code from this second exe and put it in the main project as we need the exe to effectively remain sealed, as we are also distributing it to third parties.
Options being considered:
Should I add the exe as a file within the project and set Copy to Output as 'Copy always' and then just run it from the main application folder?
Should I add the exe as a reference in the main project? If I do this how would I then call it as an executable with parameters?
I would be grateful for some guidance on the above approaches, and indeed if you have any other ways of achieving my goal.
Thanks!
There are two different ways of executing the code in the exe file:
As a separate process: use System.Diagnostics.Process and pass in any information as command line arguments
In the same process, using normal .NET method calls
In the same process in a separate AppDomain
Both of these work fine; in the first version you wouldn't need your main project to refer to the exe at all: just include it in your setup/deployment project, if you have one. If you're using xcopy deployment (i.e. just taking the contents of the output directory) then you could add a reference to the exe just to get it copied.
To use the second form you'd need to add a reference to the exe file in your project. If you're happy to call the code in-process this is likely to be the simplest solution.
The third form could use a reference but doesn't have to. This gives more isolation than the second option but less than the first.
Copy to output is, of course, the simplest solution.
If you don't want to have this exe hanging around together with your app files, put it to resources and when your application needs to run that exe, just save it to temp folder and run from there.
Here's proof-of-concept code:
class Program
{
static void Main(string[] args)
{
var fileName = Path.ChangeExtension(Path.GetTempFileName(), "exe");
File.WriteAllBytes(fileName, Resources.QueryExpress);
var queryAnalyzer = Process.Start(fileName);
queryAnalyzer.WaitForExit();
}
}
In project properties go to Resources and drag-drop there your exe file. This sample is using application named QueryExpress.exe.
You may also wish to compress your app into ZIP file to make it smaller. This will add one more step to unpack archive before running the process.
You can also make it as Dll Assembly and call it from your application, I meant loading the assembly at run time if it's existed.
Adding a reference to that exe won't help, unless you want to use classes from the exe in you main program. I think your first option is the best