I've written a script in c# which I have to execute on a daily basis. It's something like an updater for my data base. So it pulls some data from the Active Directory using CSVDE, and saves that info into csv files in the same directory, then parses those files and updates my database if necessary. Obviously I don't want to run it manually every day, so instead I added a scheduled task. My problem is that it doesn't create the expected files, at least in the same path. If I run the script manually it works like a charm. Also after a scheduled run I tried to find those files by filename on the machine to check whether those were created in some other place, but no luck.
Do you have any idea why it not works the same way?
It was some issue with the credentials under the script ran. Solved now.
Related
I have a Gauge Test Project in c# (not in core) hosted in a server. Then there is an external tool that sends the gauge run command for different tags. It sends 17 run commands almost at the same time with different tags. I have limited the concurrency of calls for 10 so only 10 get through (kinda off topic). However, for this 10 requests it seems that gauge still needs to use the gauge-bin folder as rarely I get the following error:
D:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3101: Could not write state file "obj\Any CPU\Debug\TestAutomation.csprojResolveAssemblyReference.cache". The process cannot access the file 'D:\home\site\wwwroot\Gauge\Apps\TestAutomation\obj\Any CPU\Debug\TestAutomation.csprojResolveAssemblyReference.cache' because it is being used by another process. [D:\home\site\wwwroot\Gauge\Apps\TestAutomation\TestAutomation.csproj]
D:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(4411,5): error MSB3491: Could not write lines to file "obj\Any CPU\Debug\TestAutomation.csproj.FileListAbsolute.txt". The process cannot access the file 'D:\home\site\wwwroot\Gauge\Apps\TestAutomation\obj\Any CPU\Debug\TestAutomation.csproj.FileListAbsolute.txt' because it is being used by another process. [D:\home\site\wwwroot\Gauge\Apps\TestAutomation\TestAutomation.csproj]
I know those files are located in obj\Any CPU\Debug. I don't know how to find a work around to avoid this error. My first thought is to delete the files inside the obj folder as the test seems to run fine after that. However, the files are still generated when I execute a test.
This error indicates that there are multiple msbuild processes trying to build the same project concurrently. This causes the resource conflict in the obj folder.
If you need to run the same Gauge project at the same time, Could you try something like this:
build the project first (outside gauge).
set GAUGE_CUSTOM_BUILD_PATH to the location of the output folder from above..
run gauge run specs
This will use the prebuilt binaries to execute the tests. You may also see an improvement in the run time.
There are several threads on SO that describe how to check which application creates a file with tools like Sysinternals process monitor. Is something like this possible programmatically from .net?
Background: My program has to remote-control a proprietary third party application using its automation interface, and one of the functions I need from this application has a bug where it creates a bunch of temporary files in %TEMP% that are called tmpXXXX.tmp (the same as .net's Path.GetTempFileName() does) but does not delete them. This causes the C drive to become full over time, eventually failing the application. I already filed a bug to the manufacturer, but we need a temporary workaround for the time being, so I thought of putting a FileSystemWatcher on %TEMP% that watches tmp*.tmp, collects these files, and after the operation on the third-party application finishes, deletes them. But this is risky as another application might also write files with the same file name pattern to %TEMP% so I only want to delete those created by NastyBuggyThirdPartyApplication.exe.
Is this anyhow possible?
This kind of things is possible, but maybe a bit tricky.
To know who created the file, look at the user that owns it. Therefore you might need to create a specific user, and that application will run under this specific user. In order to do that, you need to create a small application that will start your buggy app by impersonating another user, so anything done within the app will be under this user so as file creating...
I don't know how to monitor and get triggered when a file is created, but nothing can prevent you from setting a timer that wakes up every five or ten minutes, then checks if any file in the directory is owned by the application user and closed, so it deletes it.
Maybe if they react fast for this bug fixing, you won't need your app very long time. So another solution, if possible might just to change the Temp folder into another drive, which has lots of space...
One solution is that you use a FileWatcher to automatically delete all the files but before deleting you should check if the file is not currently locked or used by other process, for example the Sysinternal Suite has a tool called handle.exe that can do this. Use it from the command line:
handle.exe -a
You can invoke this from a c# program (there might be some performance issues though)
So what you would do is when a file is created you verify if it is in use or locked (for example u can use the code provided in Is there a way to check if a file is in use?) and then delete it.
Most of the time when an app is using a temp file it will lock it to prevent just what you fear, that you might delete files from other processes.
As far as I can tell there is no sure way to identify which process created a specific file.
I've developed a service that watches one directory and then if a file is created or changed it will spin up another small c# script that will determine what to do with that file. I need this to be constantly listening to the directory at all times(even on start up of the server) because a file could be generated in this directory at literally any time.
I've searched and tried a few things but each time. The service will run then a file will be generated...then it launches the other C# script and does what it needs to with that file and then the service stops. So next time something happens in that directory nothing happens. Is there something I'm missing? How would I go about doing this?
So, your C# service will be stopped working after the first time that it runs your C# script?
I think it should related to your service configuration.
Checkout these links to see how you should create a service through C# :
http://www.codeproject.com/Articles/3938/Creating-a-C-Service-Step-by-Step-Lesson-I
http://www.codeproject.com/Articles/106742/Creating-a-simple-Windows-Service
http://www.codeproject.com/Articles/400697/WCF-Service-Creation-With-Csharp
I hope it helps you to find your mistake.
(If there's sth else, tell in comment)
I have a sql serevr database in a remote system .I am using ADO.net to bring that database table values into my local mysql server .
Now i want to fetch data from remote db into my local db every 15 min .I think this will involve running the program every 15 min.Please suggest if there is any better way .I want to make it automatic.
I tried with putting the package.dtsx in schedule task . It doesnt work .I think we can make an exe file and then run it
Can you tell me how do i make an exe file?
How do i do this.
Thanks
Since you've tagged your question with Visual Studio 2008, I'll assume you have that.
Create a new project of type Console Application. If you add your code to that project and compile it, the result will be a .exe file which you can run as a Scheduled task.
However, since you are talking about a .dtsx package, another option would be to add your .dtsx package as a scheduled job in the server you are trying to import data to.
Read this on how you schedule a job in SQL Server.
we are using some private MSMQ queues with our production system. Since implementing, we've had to update some stuff with the queues and re-create them to work with updated code. We have over 200 machines that need these updates so I'm working on a program that will be pushed via SMS to do this update.
What I'm noticing is that the only person that can run my program to do the update is the one that originally setup the private queue on that particular machine. Because of the number of machines, there were multiple admins that setup these queues.
Since not all of the employees still work here, this is causing me [my program] a problem. The permissions are not allowing the program to update everything that I need. I googled and found this link http://social.msdn.microsoft.com/Forums/hu-HU/msmq/thread/36a3d910-d533-4af3-86dc-498d00c68fef that shows how to update the permissions by modifying the file that is created for each of the queues. Great! It works when I manually navigate to that path and do the update. Now I want to do it programmatically via SMS push.
When trying to run this from my program, I get an error back saying the directory does not exist "C:\Windows\System32\msmq\storage\lqs". Huh? When I enter that path into Start->Run, it brings up the folder just fine. Well, breaking on the if (Directory.Exists(path)) part of my code definitely returns a false. If I remove all of the folders beyond System32, then the Directory.Exsts works just fine.
Why can't my program determine whether or not that msmq folder exists? I've tried "running as administrator" and it still returns false. What do I need to do to get that check to work?
Thanks
Edit: This is really weird, I have a FindAndReplace API that I wrote that will take in a path (file or directory), find text, replace text, etc. When I'm running that program from my Find And Replace GUI wrapper, it works just fine. But when I'm calling this API from my update program, it says that directory doesn't exist. This is really confusing. (I should probably remove the MSMQ tag because it has nothing to do with my question...)
Project + Properties, Build tab. Change the "Target platform" setting from x86 to AnyCPU. This lets you program run in 64-mode so the c:\windows\system32 directory search doesn't get redirected to c:\windows\syswow64.