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.
Related
I am new in mvc and c# and I can't solve following problem:
I am trying to create a folder named "Items" in solution folder.
I have tryed to use CreateDirectory method:
Directory.CreateDirectory("~/Images");
But it didn't work for me - folder wasn't created ..
Partly working solution was to create a folder by :
Directory.CreateDirectory(Server.MapPath("~/Images"));
"Items" folder was created, but it is not included in the solution:
How to create folder in solution directory so that it is included in project ?
(I needs to by done by code not by hand)
You need to understand what solution and csproj file is used for
In general, they're being designed and used for development with Visual Studio, and once the project is compiled, all these files will be ignored and excluded from the deployment package
Directory.CreateDirectory(Server.MapPath("~/Images"));
The code above simply create the directory if not existed yet in the deployment package at run-time, so you won't see it in your solution unless you run the project locally (either debug/release mode, it does not matter here). However, everything will run normally in hosted environment (ex: IIS).
For your information, here's the brief of what solution and csproj is
solution (.sln) file: contains information to manage one or many individual projects, contains build environments (for each project), start up mode (useful when you want to start multiple projects in one run), project dependencies and so on. Take a note that VS also read from suo file (solution user options) which is used to defined user-custom preferences (you should not include the .suo file in the version control, because it's custom settings)
csproj file: define the structures of project, what the namespace is, what is static folders, embedded resources, references, packages, etc.
Lastly, if you create the folder manually, VS will auto include that folder into deployment package AND csproj, but depends on the file type, you might need to change the Build Action and Copy To Output Directory in file properties.
Hope it helps.
A deployed web application on a web server doesn't have any notion of Visual Studio solution or projects. So the Directory.CreateDirectory(Server.MapPath("~/Images")) is the correct way to create a folder inside your web application at runtime but we cannot be talking about including it into a solution because this hardly makes sense in a pre-compiled web application. If you create the directory on your local development machine, you could always manually include the folder to the corresponding .csproj file, but at runtime this will not make any difference whatsoever.
The reason I wanted to create a folder (if didn't exist) was to make sure it exits before I try to store image in it.
After reading posts here and a few google searches I have concluded that the proper way to handle image upload would be
To create (In my case) folder "Images" by hand to be sure it exists
Then storing uploaded img in existing folder:
string path =Server.MapPath("~/Images/"+ UploadedImageName);
file.SaveAs(path);
So I want to create a C# application that can be transmitted to users which can then run an "exe" file copying the data files. Therefore, the application should contain at least to things:
The "exe" file
The files containing the data
The data in the application will be in most cases a directory with files and subfolders. My concern is how to store this data. I was thinking about storing the data in ".bin" files while being able to read the data with the exe file and place the files/folders in the correct structure, but I don't know exactly how would I do that with files and folders. Does anyone have any suggestions ? Is there a better way? Do you have any recommended reads ?
Thanks!
When you compile in either debug or release mode, there will be an .exe file in the bin/debug or bin/release folder for your project together with all the project files. You can move that to whatever machine with the .NET framework installed and run the .exe.
If you want to make an actualy executable, that's more difficult to do. Check out this post for more inspiration on that.
If your build is meant for distribution, better compile it on Release mode.
You will find the assemblies on your project_folder/bin/Release.
You may want to copy all contents in the release folder by compressing it, or better yet, using an installer compilation tool, like InnoSetup - http://www.jrsoftware.org/isinfo.php/, that is free and will do your application installer just fine.
I made a WPF program which uses SQLite. And by using Visual Studio 2012, it generates both Debug and Release version exe file. When I go to Debug or Release directory and run my exe file, e.g. MultiStart.exe, it can run normally.
But if I copy the MultiStart.exe to my Desktop and try to run it, it failed.
By several tests, I found that I also need to copy files MultiStart.exe.config and System.Data.SQLite.dll to my Desktop. And then it can run now.
But why? Do we have better solution so that I can make it run without addition files?
Thanks!
Why my WPF program cannot run without Visual Studio?
The question title is not really accurate since it's not really related Visual Studio. MultiStart.exe is dependent on configuration (MultiStart.exe.config) as well as other assemblies (System.Data.SQLite.dll). Without these dependencies the application cannot run (because that is how .NET works).
WPF doesn't necessarily need a config file to run so the question is what is in your config file that the application needs. It might be possible to move this configuration information into the code (e.g. connection string) and remove the app.config but then the values will be hard coded in the application.
In terms of dependent assemblies, instead of deploying them it is possible to embed them as resources and then use the AppDomain.AssemblyResolve Event to read the assembly from a resource (see Embedding assemblies inside another assembly for an example).
Another approach instead of embedding assemblies as resources is to merge them into one assembly. ILMerge is a popular choice for merging assemblies but I read that it can have issues with WPF assemblies (not sure if that applies to you). See Merging dlls into a single .exe with wpf for some other ideas for merging assemblies with WPF.
Note that setting PATH variables does not work because .NET does not use the PATH for resolving assemblies -- see How the Runtime Locates Assemblies for the details.
Another, option instead of copying the MultiStart.exe to the desktop is to use a shortcut on the desktop that links to the appropriate directory. Perhaps that is a simpler solution
You can also use ILMerge to merge all dependencies into single .exe file to simplify distributiuon of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
Example of usage: ilmerge /target:winexe /out:YourDestinationApp.exe
YourCurrentProgram.exe System.Data.SQLite.dll
Better solution that i used to do with my windows form apps is, Copy the entire folder, which contains supporting files. place it where you want. then create a shortcut of your .exe on your desktop. That always worked for me.
Because you are missing some dependency. You can open your config file and set the dependency...but I wouldn't recommend you to change config file manually.
You can also copy the dependent dll in system32 folder. ..but its only a trick because exe first search dlls in current folder than system 32 folder.
Because you're missing things from your PATH. Visual Studio is probably set to copy DLLs to the target directory on build.
You're almost certainly pulling in external libraries. Some of these are part of .NET, while others are packaged in libraries in specific folders. When you start your exe, it looks in your PATH and the current folder for everything (which includes all DLLs Visual Studio copied).
When you moved the exe to the desktop, suddenly it had no idea where those DLLs are. You haven't specifically added them to your PATH, and they are no longer in the current folder. This is why copying those DLLs to your desktop magically made them work.
Unless you stop use SQLite, there is not a way for you to not need that DLL (there are lots of ways to package/reference it though).
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 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...