I've had a scout around some answers to similar questions but they haven't really helped me much.
I have an app, into which I've embedded some resources. At launch the app checks to see if the resources exist in the appdata folder and if not copies the template files from the embedded resources to the appdata folder before loading them and then using the ones in the appdata folder as the working copies.
I have a helper class which amongst other things returns the appdata and resources subfolder as follows:
class Folders
{
static public String GetUserFolder()
{
return Application.LocalUserAppDataPath;
}
static public String GetResourcesFolder()
{
// If the resources folder does not exist then create it
String userFolder = GetUserFolder();
String resourcesFolder = userFolder + "\\Resources";
if (!Directory.Exists(resourcesFolder))
{
Directory.CreateDirectory(resourcesFolder);
}
return resourcesFolder;
}
...
So my code calls the GetResourcesFolder method which returns the path (creating the folder in the process if it needs to) checks to see if the file exists and if it doesn't tries to write to it using something like:
String filename = Helpers.IO.Folders.GetResourcesFolder() + "\\data.dat";
FileStream outFile = System.IO.File.OpenWrite(filename);
So I've set the scene and this code is working on all the machines I had in the development office. However a couple of off site colleagues have complained it "crashes" on their machines - in each case an XP machine - but otherwise not a lot of useful information coming back from them - working on trying to get something more informative from them. I have XP machines in the office that it has worked on without problems.
After digging out some really old dev machines that were "archived" a while ago, I've managed to have a crash on two xp (sp2) machines also. On both occasions the crash seems to be related to write permissions and running the app using "Run As..." has resolved the problem and it executes correctly. However once the app has been successfully run once the app no longer crashes, even if I delete the files/folders it created from the appdata folder it will still create the successfully on subsequent executions even if I don't elevate permissions.
The problem I have is that I can now no longer repeat the crash on any dev machines available to me and I don't know how to go about putting the machine back into the state where I can.
Anybody got any ideas on what might be causing the problem, or how I may be able to return the machines to a "virgin" state to be able repeat the crash and help me track it down.
One course of action is to create a Virtual Machine of XP. You can save the state of the machine before install for testing. After your install just revert back to the previous state to test again. There are a few Vendors with free Virtual Machines:
http://www.microsoft.com/windows/virtual-pc/
https://www.virtualbox.org/
As too the related problem itself, I don't know a better way than to install VS on a virtual machine for testing purposes.
+1 to Erik's VM solutions for reporducing the issue.
For tracking down permissions issues consider using ProcMon ( http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx ) - will show enverything you ever wanted (and not :) ) about file/regisstry access made by a process. I'd recommend trying it several times first on machine where you program works fine to get filtering setup for your process and get a sense of what should be happening.
Related
I'm currently running into an odd little problem in an installation wizard. On one single test VM--all the others are fine--I cannot create subdirectories in a directory I created. On the first screen I select an install location and, if it doesn't exist, create it:
c:\Program Files\Foo
Then a couple screens later, I get user credentials for the software to use and, to make sure they have the appropriate permissions, use them via impersonation to create subdirectories under Foo, say Bar and Baz. The impersonation I'm using is based on link.
The thing is, if I'm logged in as myself, that first directory is created just fine. But if I put my EXACT SAME CREDENTIALS into that later screen, it fails to create those subdirs. Despite the fact that it's the same creds that the program itself are currently running under.
Also, as I said, this works literally everywhere else except this one machine. So it doesn't make any sense. All we can figure is something broken about the impersonation system. That's all we can figure. But you'd think it would show up elsewhere. If it was something with the VM, then how did we create the Foo directory in the first place?
Anyway, any suggestions would be most welcome. This is really nutso.
EDIT: I have verified my account is local Admin on the VM. Nothing helpful in the Event viewer. Also, fixed link to MS impersonator code.
I am using VS2013 Premium to publish a site to Windows Server 2012.
All files publish ok except these:
SqlServerTypes\x64\msvcr100.dll
SqlServerTypes\x64\SqlServerSpatial110.dll
SqlServerTypes\x86\msvcr100.dll
SqlServerTypes\x86\SqlServerSpatial110.dll
I get this kind of errors for each of the above files I tried to publish:
Web deployment task failed. (The file 'msvcr100.dll' is in use. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
Interrestingly, these files were published the first time (when they were not on the server), then they are no longer overwritten. Tried with 2 different web servers.
I have followed the guide here:
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
...But it only managed to put the site offline (VS is placing the app_offline.htm) but publish still fails with the same error.
All other files publish perfectly.
Any ideas?
You can take you app offline during publishing which hopefully should free up the lock on the file and allow you to update it.
I blogged about this a while back. The support outlined was shipped inside of the Azure SDK and Visual Studio Update. I don't remember the exact releases but I can find out if needed. Any update dating around/after that blog post should be fine.
Prerequisites:
VS 2012 + VS update / VS 2013 + VS Update / VS2015
MSDeploy v3
Note: if you are publishing from a CI server the CI server will need the updates above as well
Edit the publish profile
In VS when create a Web Publish profile the settings from the dialog are stored in Properties\PublishProfiles\ as files that end with .pubxml. Note: there is also a .pubxml.user file, that file should not be modified
To take your app offline in the .pubxml file add the following property.
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
Notes
ASP.NET Required
The way that this has been implemented on the MSDeploy side is that an app_offline.htm file is dropped in the root of the website/app. From there the asp.net runtime will detect that and take your app offline. Because of this if your website/app doesn't have asp.net enabled this function will not work.
Cases where it may not work
The implementation of this makes it such that the app may not strictly be offline before publish starts. First the app_offline.htm file is dropped, then MSDeploy will start publishing the files. It doesn't wait for ASP.NET to detect the file and actually take it offline. Because of this you may run into cases where you still run into the file lock. By default VS enables retrys so usually the app will go offline during one of the retrys and all is good. In some cases it may take longer for ASP.NET to respond. That is a bit more tricky.
In the case that you add <EnableMSDeployAppOffline>true</EnableMSDeployAppOffline> and your app is not getting taken offline soon enough then I suggest that you take the app offline before the publish begins. There are several ways to do this remotely, but that depends on your setup. If you only have MSDeploy access you can try the following sequence:
Use msdeploy.exe to take your site offline by dropping app_offline.htm
Use msdeploy.exe to publish your app (_make sure the sync doesn't delete the app_offline.htm file_)
Wait some amount of time
Publish the site
Use msdeploy.exe to bring the app online by deleting app_offline.htm
I have blogged how you can do this at http://sedodream.com/2012/01/08/howtotakeyourwebappofflineduringpublishing.aspx. The only thing that is missing from that blog post is the delay to wait for the site to actually be taken offline. You can also create a script that just calls msdeploy.exe directly instead of integrating it into the project build/publish process.
I have found the reason why the solution at
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
did not work for the original poster, and I have a workaround.
The issue with the EnableMSDeployAppOffline approach is that it only recycles the app domain hosting the application. It does not recycle the app pool worker process (w3wp.exe) which the app domain lives in.
Tearing down and recreating the app domain will not affect the Sql Server Spatial dlls in question. Those dlls are unmanaged code which are manually loaded via interop LoadLibray calls. Therefore the dlls live outside the purview of the app domain.
In order to release the files locks, which the app pool process puts on them, you need to either recycle the app pool, or unload the dlls from memory manually.
The Microsoft.SqlServer.Types nuget package ships a class which is used to load the Spatial dlls called SqlServerTypes.Utilities. You can modify the LoadNativeAssemblies method to unload the unmanaged dlls when the app domain is unloaded. With this modification when msdeploy copys the app_offline.htm the app domain will unload and then unload the managed dlls as well.
[DllImport("kernel32.dll", SetLastError = true)]
internal extern static bool FreeLibrary(IntPtr hModule);
private static IntPtr _msvcrPtr = IntPtr.Zero;
private static IntPtr _spatialPtr = IntPtr.Zero;
public static void LoadNativeAssemblies(string rootApplicationPath)
{
if (_msvcrPtr != IntPtr.Zero || _spatialPtr != IntPtr.Zero)
throw new Exception("LoadNativeAssemblies already called.");
var nativeBinaryPath = IntPtr.Size > 4
? Path.Combine(rootApplicationPath, #"SqlServerTypes\x64\")
: Path.Combine(rootApplicationPath, #"SqlServerTypes\x86\");
_msvcrPtr = LoadNativeAssembly(nativeBinaryPath, "msvcr100.dll");
_spatialPtr = LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial110.dll");
AppDomain.CurrentDomain.DomainUnload += (sender, e) =>
{
if (_msvcrPtr != IntPtr.Zero)
{
FreeLibrary(_msvcrPtr);
_msvcrPtr = IntPtr.Zero;
}
if (_spatialPtr != IntPtr.Zero)
{
FreeLibrary(_spatialPtr);
_spatialPtr = IntPtr.Zero;
}
};
}
There is one caveat with this approach. It assumes your application is the only one running in the worker process that is using the Spatial dlls. Since app pools can host multiple applications the file locks will not be released if another application has also loaded them. This will prevent your deploy from working with the same file locked error.
There are known issues with IIS and file-locks (why they aren't solved yet i dont know).
The question i want to ask however is if you even need to re-deploy these files?
I recognize the file-names and recall them to be system-files which should either already be present on the server or simply not need to be re-deployed.
I am not very experienced when it comes to IIS but i have ran into this problem before and several of my more experienced co-workers have told me that this is as i said a known IIS-issue and i believe the answer to your question is:
Avoid deploying unnecessary files.
try again
Reset website
try again
iisreset
I think what would be the easiest thing to do is to make these dll's as CopyLocal as true. I am assuming these dll's are pulled out from program files folder. Try marking them as copylocal true and do a deployment.Try to stop any IIS local process running in your local machine.
Watch out you don't have one of those new-fangled cloud backup services running that is taking file locks - and also you don't have things open in explorer or a DLL inspection tool.
I think it's kind of ridiculous that MS doesn't make better provisions for this problem. I find that 9 times out of 10 my deployment works just fine, but then as our traffic increases that can become 1 in 10 times.
I am going to solve the problem with :
two applications MySite.A and MySite.B, where only one is running at a time.
I always then deploy to the dormant site.
If there's a problem during the deployment it will never cause the whole site to go down.
If there's a major problem after deployment you can revert back very easily.
Not quite sure how I'm implementing it, but I think this is what I need to do.
I have some VB6 .ocx files that I would like to register. These .ocx files would be on a remote machine.
What is the best way to register these .ocx files programatically?
string arg_fileinfo = "/s" + " " + "\"" + "\\<remotemachine>\\<directory>\\<ocx>" + "\"";
Process reg = new Process();
//This file registers .dll files as command components in the registry.
reg.StartInfo.FileName = "regsvr32.exe";
reg.StartInfo.Arguments = arg_fileinfo;
reg.StartInfo.UseShellExecute = false;
reg.StartInfo.CreateNoWindow = true;
reg.StartInfo.RedirectStandardOutput = true;
reg.Start();
reg.WaitForExit();
reg.Close();
I'm not getting any errors but it isn't registering the .ocx either. Any ideas?
If you want to register a remote file for use on a local machine, there is nothing special required for registering a file on a UNC path, but you do need to make sure that the UNC path or mapped drive is still available to all users, especially the user that is running regsvr32. Presumably, this will be the local admin which (by default on Windows Vista+) will require elevation which can disconnect network connections.
Also note that your example is missing the extra \ from the beginning of the UNC path. Your code will result in arg_fileinfo containing /s "\<remotemachine>\<directory>\<ocx>".
You can add the extra \, or use the # decorator which makes it a lot clearer when entering Windows paths:
string arg_fileinfo = "/s \"" + #"\\<remotemachine>\<directory>\<ocx>" + "\"";
Or just use it for the entire string and the alternative quote escaping method:
string arg_fileinfo = #"/s ""\\<remotemachine>\<directory>\<ocx>""";
Take this as a warning you're free to ignore (because I know you will anyway):
Doing this isn't a good practice. Just to begin with "run from network" PE files (EXE, DLL, OCX) need to be specially linked for it or you risk high network activity and crashes due to intermittent network interruptions. And registering anything not on the boot drive or at least a local hard drive isn't sensible anyway. Doing any of this ranks high on the "poor practices" list even though it might seem to work most of the time.
Why not just do normal deployment following accepted practices?
My guess would be that you are doing a lot of Mort development, throwing together version after version of some program hoping one of them will eventually "stick." So you want to dump some or all of it onto a network share, thinking "Installation? Installation? We don't need no steenking installation. I can just plop new files out there and have everything magically work with no effort."
I'll assume you don't have the luxury of a managed network you can use to push out updates via Group Policy, and that you aren't creating the necessary MSI installer packages handling the Product and Upgrade Codes in them.
One alternative would be to use reg-free COM, which will solve a lot of small issues for you.
Now, you could do this and still ignore the hazards of PE files run from a network share, or you could bypass that using a small launcher program. That launcher could check a network share for a new version, and if found copy the newer files to the local PC before starting the actual application and terminating. This is basically an auto-updated XCopy Deployment technique.
You can get as fancy as need be. For example if your application accepts command line parameters it might do the new version check itself and if found then start the small updater (passing it the command line parameters), then terminate. The updater app could restart and pass those parameters to the new version.
But yes, life as Mort (or even an official on-the-payroll developer) can be a pain. It can be extremely difficult to get the attention of your friendly neighborhood box jockeys to do things properly even if you are working in a managed corporate LAN environment. That goes double if your application isn't part of some highly engineered sanctioned Major Project.
I had to do this several years ago. As best I can remember, UNC names wouldn't work, a mapped drive letter was required. Whether it was strictly a regsvr32 issue, or was caused by something else (e.g. Windows 95) is lost in the fog of time.
If you want to register the file for use on the remote machine, you you need to run the code on that remote machine.
You can either do this by physically sitting in front of the computer, using remote control software, or a remote admin tool like psexec.exe.
I'm working on a online only winform application which I deploy using ClickOnce feature it uploads through FTP to the server and the user executes it online through http.
As you may already know, the Online only feature doesn't place any icons on the desktop, so everytime it runs the user got to run the setup.exe file to do it.
My question is, if there is anyway I could actually create an icon that may point to the setup file or any workaround to make sure the user got an accesible and easy way to run the app without having to look for the setup file everytime?
Users may not know a lot about computers so it can be a hard task to navigate all the way to the downloaded file everytime, and I want to make it easier for them.
I know that if I do an offline/online app it will solve the problem, but I would like it to be online only.
Any ideas?
you can create desktop shortcut manually on the first app run, and point it to either to your app's url, or path to downloaded file (I guess, url will be safer in case user deletes the file). Code can look something like this (need adjusting to your URL):
void CheckForShortcut()
{
ApplicationDeployment ad = ApplicationDeployment.CurrentDeployment;
if (ad.IsFirstRun)
{
Assembly code = Assembly.GetExecutingAssembly();
string company = string.Empty;
string description = string.Empty;
if (Attribute.IsDefined(code, typeof(AssemblyCompanyAttribute)))
{
AssemblyCompanyAttribute ascompany = (AssemblyCompanyAttribute)Attribute.GetCustomAttribute(code,
typeof(AssemblyCompanyAttribute));
company = ascompany.Company;
}
if (Attribute.IsDefined(code, typeof(AssemblyDescriptionAttribute)))
{
AssemblyDescriptionAttribute asdescription = (AssemblyDescriptionAttribute)Attribute.GetCustomAttribute(code,
typeof(AssemblyDescriptionAttribute));
description = asdescription.Description;
}
if (company != string.Empty && description != string.Empty)
{
string desktopPath = string.Empty;
desktopPath = string.Concat(Environment.GetFolderPath(Environment.SpecialFolder.Desktop),
"\\", description, ".appref-ms");
string shortcutName = string.Empty;
shortcutName = string.Concat(Environment.GetFolderPath(Environment.SpecialFolder.Programs),
"\\", company, "\\", description, ".appref-ms");
System.IO.File.Copy(shortcutName, desktopPath, true);
}
}
}
credits to http://geekswithblogs.net/murraybgordon/archive/2006/10/04/93203.aspx
What is your reason for wanting an online only ClickOnce app? I always recommend offline unless your app is really an edge case.
There's very little difference between online and offline. All the same files are downloaded to the same location on the client. Offline apps add an entry to the 'Add/Remove Programs', a start menu shortcut, and an optional desktop shortcut (if you are targeting .NET 3.5+). The ability to uninstall through Add/Remove Programs is key. It makes supporting your application much easier when users have install problems.
Also, you mention users running the setup.exe every time. This is unnecessary. The setup.exe will contain your bootstrapped pre-requisites and then launch the app when it finishes. If the user has run the setup.exe once, they only need to click the link to the .application file. That will definitely speed up the app's start time. Also, in many cases the user has to have admin privileges to run the setup.exe; clicking the .application doesn't (assuming someone with admin privileges has already run the setup.exe).
In conclusion, there really isn't an answer here :). But...
Make absolutely sure your reasoning is sound for not doing an offline install instead.
After running the setup.exe once, direct users to click on the .application url (or the desktop shortcut if you switch to offline) instead of the setup.exe.
As far as I know, there is no reliable way for running online only ClickOnce application than creating shortcut to that setup.exe.
This snippet works well if I try to write in a user directory but as soon as I try to write in Program Files, it just executes silently and the file has not been copied (no exception). If I try to copy the file in C:\ or in C:\Windows I catch an UnauthorizedAccessException.
Do you know another way to get the permissions to write in that directory or to make it work another way?
Any help greatly appreciated! Thanks
using(FileStream fs=File.Open(source, FileMode.Open)){ }
try
{
FileIOPermission fp = new FileIOPermission(FileIOPermissionAccess.Write,
AccessControlActions.Change, "C:\\Program Files\\MyPath");
fp.Demand(); //<-- no exception but file is not copied
File.Copy("C:\\Users\\teebot\\Documents\\File.xml","C:\\Program Files\\MyPath\\File.xml",true);
}
catch(SecurityExceptions)
{
throw(s);
}
catch(UnauthorizedAccessException unauthroizedException)
{
throw unauthroizedException;
}
If you are running under Vista then the system just redirects writes to the program files folder, this is done so old program that keep their configuration in the program directory will continue to work when the user is not an Admin (or UAC is enabled).
All you have to do is add a manifest to your program that specify the required access level, then the system assume your program is Vista-aware and turns off all those compatibility patches.
You can see an example of a manifest file on my blog at:
http://www.nbdtech.com/blog/archive/2008/06/16/The-Application-Manifest-Needed-for-XP-and-Vista-Style-File.aspx
(the focus of the post is on getting the right version of the common controls, but the Vista security declarations are also there)
Don't write in the Program Files folder.
That's a big no-no, and will especially cause problems when the day comes where your code runs in Vista or on a machine at a company where users only get standard security rather than admin rights. Use the Application Data folder instead.
Are you running on Vista? If so then you may be running into file system virtualization. This is a feature in 32 bit versions of Vista which allows a normal user to write to protected parts of the file system. It's a shim introduced to reduce the pain of the LUA features of Vista.
The short version is that the operating system will create a virtual file system for certain protected roots (such as program files). When a non-admin attempts to write to it, a copy will be created an editted instead of the original. When your user account attempts to look at the file it will see the edit.s Other user accounts will only see the original.
Longer Version: http://thelazyadmin.com/blogs/thelazyadmin/archive/2007/04/26/file-system-virtualization.aspx
Code access security grants or denies permissions to your code.
It can't be used to override permissions that are granted/denied to the current user.