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.
Related
I have finished a very basic application (wpf/c#). The solution is made of 3 projects:
The main project for the app
The Class Library Project to store app resources (images and txt files)
The Setup project which I use to create exe file for distribution to other
machines.
While the project works fine in debug mode when I deploy it using the Setup project and install on the computer I can access the image files from the Library Project (I can see there is a dll file for the library project in the application folder) but it fails to access the text files, complaining the path was not found. This is my very first time I completed the application and attempted to deploy it so am a bit at a loss why the setup does not provide correct references to the text files and yet it seems to work fine with image files which are located in the same library project.
Can someone point me in the right direction where to look at it to troubleshoot?
I have cleaned and rebuilt all projects in the solution. retested in debug mode (works fine). tried to search msdn and StackOverflow but I cannot find any guidance I could use or follow.
I would like to be able to display text from the text files in the released/installed application version the same way it works in debug mode. At the moment it fails to find the relevant txt files.
Finally, I have managed to crack it. Posting the answer for anyone having the same problem.
The issue here was not with the file path, even though I came up with a more clearer technique of building it, see my comments above. The problem was with the way Setup Project in VS2017 was creating a package. It is handling differently images and text files, even though both are in the same Library Project, essentially for text files I had to do the following to get it working:
Open File System in Setup Project
Create the 'Resources' Folder under 'Application Folder'
Set the 'Resource' folder 'AlwaysCopy' property to 'true'
In 'Resources' folder right-click and select Add> File...
Navigate to the folder with the files and select them all (make sure the files are setup as Resources or embedded resources)
Rebuild the Setup Project
.
So summarising I had to specifically tell Visual Studio to build the folder structure in the Application Folder during the install.
Now when I run the installer the text files are included in the package and created during standalone installation. Also included a screenshot below.
I'm using visual studio community 2013 on Windows 10 home for development of a c# AI application. The application works fine if it runs from the development folder, however, because I want to be able to keep the application running while modifying and compiling existing code, I copied the exe and DLLs (1 exe, 2 DLLs, debug build) to a different folder to be run from there.
When run from the copied folder, the exe (only the exe) is deleted when I close the application. Moreover, I cannot copy the exe back from the development folder because I get "Destination folder access denied". This happens only when I try to copy the exe (other files, including exes with different names, can be copied OK) and I have to reboot to be able to copy the exe back.
I'm not sure even where to start to debug this. Things I tried:
- Check the recycle bin to see if the deleted file is there: no
- Run process monitor to see if the exe name is running anywhere: no
- Exclude the copied folder from antivirus (AVG) scan/check: didn't help
- Make sure I'm running as administrator: yes
Have you checked the folder permissions on the destination directory? This sounds pretty much closer to a folder permission issue.
Since you haven't mentioned the Windows version in question, I am going to be generic on the approach. Try this:
Go to folder properties -> Security -> Advanced -> Owner -> Edit
Add ownership to your user account
Apply changes and retry copying files as see if it still prevails
** Also, in folder permissions, try giving full control to your user account
So, I have completed a C# console application using Microsoft Visual Studio 2012.
I have a local file within the project folder. Within my code, I have performed a log writing operation by assigning the relative path of this file to a string variable. The file was created during the first build/run and then appended with information during further runs.
string rpath = "..\\LogFile2.txt";
I built this project in debug mode and ran it. During this run the rpath is correctly identified as
c:\project_app_folder\bin\LogFile2.txt
However, while building this project in release mode and then scheduling the .exe file to run at a particular time in the windows task scheduler, I get a run-time error saying
Could not find a part of the path 'C:\local\pic'.
How do I resolve this? I want the temporary folders or text files created during run time to be part of my project folder/package?
Please also note , I cannot put absolute paths as this code will have to be packaged and sent to another user and that user may chose to store the program in a location he/she sees fit.
This issue is not because of release mode, when the scheduler invokes the program the working directory will be different as #Damien_The_Unbeliever said. you can use the "start in" option when you specify your action, as your release directory.
The "start in" is mainly to make sure that if you have relative paths
in the task to run, it understands which directory to use.
I have c# class library that it is a part of a big web site. After build, generated dll file copy to bin folder automatically by post-build event command line:
copy $(TargetPath) "C:\MyWebSite\bin"
My web site run under IIS and I want to debug my class library that its in a separated solution. How can I debug it?
In solution with your DLL which you want to debug, set break point and choose from menu Debug - Attach to Process..., then choose w3wc process with your site pool
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...