I've built a Compact Framework application and I'm using WmAutoUpdate to deploy new versions to the mobile devices (http://www.sebastianvogelsang.com/2009/09/23/wmautoupdate-a-net-compact-framework-auto-update-library/). Has anyone used this? It's cool but I've got a problem.
If I cause the application to crash half-way through updating it is supposed to recover by copying the backup version back into the main directory. This doesn't work because the exe file is "locked" by the operating system because it is currently in use. I can verify this is the case because I can't delete it using Windows Explorer either. The error details are:
System.IO.IOException was unhandled
Message="IOException"
StackTrace:
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.File.Move(String sourceFileName, String destFileName)
at WmAutoUpdate.Updater.assertPreviousUpdate()
at WmAutoUpdate.Updater..ctor(String url)
The error occurs on this line in Updater.assertPreviousUpdate():
File.Move(f, appPath + "\\" + getFilenameFromPath(f));
The code manages to update the application exe file when it's allowed to run normally (I'm not sure how). The problem is that it doesn't work when rolling back.
Cheer
Mark
I've used WmAutoUpdate and I've found the same problem. The issue is that you can move the files of the actual running process, but you cannot overwrite them. If you check the update part, WmAutoUpdate moves the running application to a backup directory and then it writes the update version to the original directory. I have fixed the rollback part this way:
if (Directory.Exists(backupDir))
{
string tmpDir = Path.Combine(Path.GetTempPath(),Path.GetFileNameWithoutExtension(Path.GetTempFileName()));
Directory.Move(appPath, tmpDir);
Directory.Move(backupDir, appPath);
}
First we move the running application files to a random directory in Temp. Then we copy the backup folder to the application original directory. Of course, this will generate a .TMP file in the Temp directory of your device, and a folder with the actual running process. You will have to delete this temporary folder once in a while in production code.
Related
I have an SSIS package, zip.dtsx. This package successfully runs on serverA. I copied this package in serverB. However, when I try to run zip.dtsx on serverB, it fails.
zip.dtsx just reads a file in a source folder, compresses it, saves the compressed file to a different folder, then deletes the original file in the source folder.
After some investigation, I figured out that if I comment out the part in the C# script task that deletes the file in the source folder. The package runs successfully.
I need to delete the file in the source folder. Otherwise, this file will just be repeatedly loaded to the database. I've already re-added the script task references as suggested here, but still I cannot make the file.delete run successfully.
public void Main()
{
String sourcePath = Convert.ToString(Dts.Variables["SourcePath"].Value);
String namePart = Convert.ToString(Dts.Variables["NamePart"].Value);
String destinationPath = Convert.ToString(Dts.Variables["DestinationPath"].Value);
FileStream sourceFile = File.OpenRead(#sourcePath + namePart);
FileStream destFile = File.Create(#destinationPath + namePart);
GZipStream compStream = new GZipStream(destFile, CompressionMode.Compress);
try
{
int theByte = sourceFile.ReadByte();
while (theByte != -1)
{
compStream.WriteByte((byte)theByte);
theByte = sourceFile.ReadByte();
}
}
finally
{
compStream.Dispose();
sourceFile.Close();
destFile.Close();
File.Delete(#sourcePath + namePart);
}
Dts.TaskResult = (int)ScriptResults.Success;
}
UPDATE:
After trying the exact same code here. and founding out that this code, deleted my file in the source folder, I tried to update my code to follow the way the file was deleted in the link. However, it still did not work. Below is how I updated my code.
String sourcePath = Convert.ToString(Dts.Variables["SourcePath"].Value);
String namePart = Convert.ToString(Dts.Variables["NamePart"].Value);
String destinationPath = Convert.ToString(Dts.Variables["DestinationPath"].Value);
FileStream sourceFile = File.OpenRead(#sourcePath + namePart);
FileStream destFile = File.Create(#destinationPath + namePart);
GZipStream compStream = new GZipStream(destFile, CompressionMode.Compress);
try
{
int theByte = sourceFile.ReadByte();
while (theByte != -1)
{
compStream.WriteByte((byte)theByte);
theByte = sourceFile.ReadByte();
}
}
finally
{
compStream.Dispose();
sourceFile.Close();
destFile.Close();
FileInfo currFileInfo = new FileInfo(#sourcePath + namePart);
currFileInfo.Delete();
I've finally figured this out.
To explain the whole situation, we have a fully running sqlserver, serverA. We want to duplicate this on serverB so that we can have a test environment at serverB. The necessary databases are restored on serverB already, all that's left are the SSIS packages and SQL Server Agent Jobs.
The main package (main.dtsx) that loads the contents of the files to the DB was failing.
From Integration Services Catalog -> Catalog folder -> right click -> Reports -> All Executions, I've learned that it is failing on Zip.dtsx that is called from main.dtsx. Zip.dtsx that compresses the file accessed, archives it and deletes it from the source folder.
After playing around with the script task in Zip.dtsx(an idea I got from Kannan Kandasamy's comments), I figured out that it's in the File.delete() part where my script task fails. Instantly, one would think that it is a permission issue.
My 1st mistake is I continued to play on my script task while executing Zip.dtsx by right click -> Execute task on Visual Studio. I kept getting the runtime error screencaptured in my previous post without realizing that I was getting it because I am using package variable passed by main.dtsx to zip.dtsx. I got hung up with this until I figured why the script task runs successfully when I replace the variables with my hardcoded pathnames.
My 2nd mistake was to replace the package variable of Zip.dtsx with my hard coded paths. Until finally, I realized that the folder accessed by Zip.dtsx is a local folder in serverB and I'm running the SQL server agent jobs in my local machine, say machineA. So, I shared the serverB local folders to my user account. For some reason, that messed up my package badly that it no longer sees the files in the folder thus my package succeeds running because it finds the folder empty.
The main solution:
I changed back the changes I did to Zip.dtsx and removed the sharing of serverB's local folders to my user account and instead added the NT Service\SQL$Instance to have full control over the source folder where the script task deletes the files. See this link to check how to add the SQLServer$Instance to the folder permission settings.
Other issues I encountered are:
When transferring packages form different servers and the packages fail, I think this is also important. I also did this step. But in serverB, I couldn't find Microsoft.SQLServer.ManagedDTS.dll. What I did is I copied this dll from serverA to serverB. Also check your system path to see what version of Microsoft SQL Server tools you are using on default and make sure that is what you reference in your script task.
At some point in time, while investigating, I encountered an error when viewing Integration Services Catalog's All Executions report. I solved this by going to C:\Temp folder. When I double click it to access it, a dialog appeared that I currently do not have access. I continued by clicking the 'continue' button in the dialog. After that, All Executions Report is running again.
The error I got from SSMS is,
TITLE: Microsoft SQL Server Management Studio
An error occurred during local report processing.
(Microsoft.ReportViewer.WinForms)
------------------------------ ADDITIONAL INFORMATION:
The definition of the report '' is invalid.
(Microsoft.ReportViewer.Common)
An unexpected error occurred while compiling expressions. Native
compiler return value: ‘[BC2001] file 'C:\Windows\TEMP\mpgc21o3.0.vb'
could not be found’. (Microsoft.ReportViewer.Common)
------------------------------ BUTTONS:
OK
I'm not sure how much of this really mattered on my case but I'm sharing it in case someone went through the same problem. I am a beginner in MS SQL Server so I think this might help someone who is also a beginner like me.
This question is related to my previous question.
I need to publish a C# application (that has been set up in IIS 6.0 and built in VS2010) to a desktop with win7.
I have set up IIS on my desktop well. Now I can install the application on my laptop by accessing the URL
http://myDesktopName.domain.com/MyApp
pointing to a physical location in desktop
e:\myPath\myApp\myAppService.svc
When I publish a new version of the web service, the application should get updated when I open it.
But, it gave me an error:
**the filename,directory name, or volume label syntax is incorrect**
After searching online, I found this error is normally caused by some unacccepted chars in the link. Here is the code that the msi (MS installer) needs to access and get the new version of the application.
System.Diagnostics.Process.Start("msiexec", "/favmuso \"" + myurl + "\"");
here,
myurl is http://myDesktopName.domain.com/MyApp/MyAppSetup.msi
Here, http://myDesktopName/MyApp/ is the virtual directory set in IIS 6.0 on my desktop. I can access and download it from IE in my laptop without any problems.
But, when the application notified me that a new version is available for updating the old one, I clicked the pop-up ballon on the application icon and then I got the error:
Error 123. The filename, directory name, or volume label syntax is incorrect.
If I try to access it from the C# code, I got the same error.
Then, I did a test by running
msiexec **/favmuso** http://myDesktopName.domain.com/MyApp/MyAppSetup.msi /Lv mapp_msi.log
In the log file, i found :
MSI (s) (80:DC) [18:04:33:089]: SECREPAIR: Failed to open the
file:http://myDesktopName.domain.com/mypath/\myAppSdetup (10).msi for computing its hash. Error:123
Error 123. The filename, directory name, or volume label syntax is incorrect.
Why my applcation setup file name was changed to
\myAppSdetup (10).msi
The "/favmuso" options can be found at
https://technet.microsoft.com/en-gb/library/cc759262%28v=ws.10%29.aspx#BKMK_Install
Any help would be appreciated.
thanks
So I noticed that you've asked this question elsewhere, and everyone was focused on the /favmuso piece of it.
I've been recently exeriencing this issue when trying to repair MSIs with a URL source when the original application was installed by SCCM 2012.
The workaround I found was to add a registry value at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer. The value below causes the MSI to skip the problematic portion of the repair and move on.
Name: SecureRepairPolicy
Type: REG_DWORD
Value: 1
To be a bit safer, you look into setting the registry value to 2 and using a whitelist as described in this Microsoft article: https://support.microsoft.com/en-us/kb/2918614. (Ctrl+F "Steps to opt-out the affected programs".)
I have a C# application that gets a list of directories inside a folder. This is done using the call
String[] projects = System.IO.Directory.GetDirectories("path/to/folder", "*", System.IO.SearchOption.TopDirectoryOnly);
This works fine on my machine, but after publishing (resulting in a setup.exe, as well as programName.application + Application Files) I tried running the program on a new machine and it threw an unhandled exception error.
The error was in regards to being unable to connect to a database, but the interesting part is that it was complaining about path not being valid, listing a path that only exists on my machine.
Does System.IO.Directory.GetDirectories not get reinitialized when running on another machine?
I guess the problem is with path/to/folder, as that path might not exist in new machine. Don't hard-code the path. Instead read it from config file (app.config using ConfigurationManager).
Problem: I am unable to delete a folder (including contents) within a
desktop folder programatically with C#. If I copy the value of
desktopDestinationPath and paste it into Windows Explorer, I can open
this folder (conclusion, the path is valid) The test -
Directory.Exists(desktopDestinationPath) - returns as true and I drop
into the code block (conclusion, the path is valid)
Directory.Delete(desktopDestinationPath, true) - throws exception
(conclusion, path no longer valid) If I copy the path value from the
exception and paste it into Windows Explorer, I can open this folder
(conclusion, the path is valid)
What I have tried: Build, Rebuild, Clean Solution, restart visual
studio. Also, If I delete the folder manually and run the code, the
folder is successfully built. However, when I run a second time, I get
the exception. Result: Puzzled look and this post. Sorry if I put
too much detail. I am open to help with a solution and criticism on
how I posted (both will help me learn) Thanks in advance! Visual
Studio Info is toward the bottom of this entry. I am using: Microsoft
Visual Studio Premium 2013 (C#).
My code:
// preceded by other code in the method
if (Directory.Exists(desktopDestinationPath)) // desktopDestinationPath is "C:\\Users\<me>\\Desktop\\<folder 1>\\<folder 2>"
{
Directory.Delete(desktopDestinationPath, true); // exception is thrown here <***> "C:\\Users\\<me>\\Desktop\\<folder 1>\\<folder 2>"
// create folder
Directory.CreateDirectory(desktopDestinationPath);
// Call a method to perform Xcopy
ProcessXcopy(SourceLoc, desktopDestinationPath);
}
// followed by an else which creates folder if it does not exist
My code is throwing the following exception: // NOTE I am using Pri.Longpath
System.IO.DirectoryNotFoundException was unhandled by user code HResult=-2147024893 Message=Could not find a part of the path 'C:\Users\ljones\Desktop\folder 1\folder2\fldr3\fldr4\fldr5\fldr6\fldr7\fldr8\fldr9'. Source=mscorlib StackTrace: at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound) at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive, Boolean checkHost) at System.IO.Directory.Delete(String path, Boolean recursive) at UnitTests.GatMinerTest.CreateDesktopDestinationFolder(String desktopPath) in c:\Users\some folder\Source\Workspaces\some folder\some folder\some folder\some file:line 93 at UnitTests.GatMinerTest.IcwIntegrationMethod() in c:\Users\some folder\Source\Workspaces\some folder\some folder\some folder\some file:line 65 InnerException:
From the web I have learned: A DirectoryNotFoundException exception
is thrown when part of a file path or a directory is not found. Verify
that the directory appears in the specified location. Check that the
directory exists in the specified location. // I am fairly (99.9%)
certain the directory exists When using relative paths, make sure the
current directory is correct. The path may be incorrect if you are
assuming an incorrect current directory. // I am fairly (99.9%)
certain the directory exists
Thank you all for your help in finding an answer. Specifically, thanks for the tips on posting a question in a more appropriate manner.
The solution was an error on my part (go figure).
In code that I did not disclose, there is a call to xcopy. I believe during testing, I had ran past that point and xcopy was working in the background (still had its hooks into my folder structure). Therefore, I couldn't delete it.
My apologies if I wasted your time. Your nudges helped push me toward finding the error in my ways.
Thanks again!
I get the following exception when I try to copy a file in my Windows Application...
Access to the path 'autorun.inf' is denied.
The file I am trying to copy is a shortcut file. However when I move the EXACT line of code in a standalone application, it executes flawlessly. Same user credentials. There is no difference on how I launch either application.
This is the line of code...
File.Copy(Path.Combine(Path.GetDirectoryName(Application.ExecutablePath), "JEE Startup.lnk"), #"C:\Documents and Settings\All Users\Start Menu\Programs\Startup\JEE Startup.lnk", true);
I tried deleting the bin folder and rebuilding. No luck.
I have no idea what is wrong.
The application is being executed on an XP machine.