I've this situation: i've buld a .net application that use .chm file as Integrated Help, when user press F1, Help.ShowHelp is invoked like in this example:
Help.ShowHelp(ctrl, HelpNamespace, HelpNavigator.TopicId, GetTopicId(ctrl));
This work like a charm on my machine in Application debug and release mode. But when i try to do the same on other machine (Windows XP, equal my working machine), when user press f1, nothing append, Help File is not opened.
I've done some tests. I'm sure HelpNamespace (string containing chm file path) is correct, i've tried do something more simple:
Help.ShowHelp(ctrl, HelpNamespace);
This work but is not context sensitive. I'm not able tu understend what append on the remote machine and why the seconth example work and first not.
Does anyone have any idea where the problem can be?
I solved this problem. My Machine is Windows XP Service Pack 3, Remote machine is Windows XP with no SP. I ask system administrator to update machine, after i've made new install of my Application and all work fine.
Before ask Administrator to update machine (that in all cases is a good practice, i don't know why a lot sys admin don't do this!) i've do this tests:
on my machine from command line i have emulated the comand probably called from Help.ShowHelp:
hh.exe -mapid 2900 ms-its:C:\Programs\AppFolder\Help.chm
if all work fine this command show chm file with Selected TopicId, this command, on remote machine don't produce anything and this is the reason that convinced me to ask for an update of the system
Related
I am having a strange problem that I am unable to access files written by my c# application. My app basically does :
var file = "C:\\Users\\Public\\Documents\\something.txt";
List<string> content = new List<string> { "one thing", "two things" };
Console.WriteLine(System.IO.File.Exists(file));
System.IO.File.WriteAllLines(file, content);
Console.WriteLine(System.IO.File.Exists(file));
The first time I run the app, the output is
False
True
Yet I cannot see the written file in Windows Explorer (Windows 10). I get no exceptions attempting to write the file. The second time I run the app, the output is :
True
True
According to my application the file is being written however Windows thinks differently. As a sanity check I spun up a second app that opens a dialog using OpenFileDialog. When I run that, I am able to see my written files! Windows explorer still cannot. Attached is a screenshot of windows explorer and my openfiledialog side by side.
If I go to notepad and browse for the file I cannot see it or manually type in the name.
Its been a long week of work, there must be some dumb explanation...? Help! :-)
Screenshot - windows explorer on left, c# app open dialog on right :
https://imgur.com/a/8ZTDIe6
per #BACON 's suggestion in the comments above I discovered that after disabling the Comodo anti-virus I am able to write and see my files.
I believe the software is running my app or either only allowing IO from my app in some kind of container. I need to figure out how to grant my apps proper permissions through the anti-virus software, but that was the culprit.
DesiredCapabilities capabilities = DesiredCapabilities.InternetExplorer();
System.Environment.SetEnvironmentVariable("webdriver.ie.driver", #"C:\\IEDriverServer.exe");
instance = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), capabilities);
I also have the a system variable set, and the IEDriverServer is in the system path. I cannot run the IEDriver from command line (which makes me thinking is there something wrong with path configuration, or some security restriction)
note that the hub and the node are one and the same machine.
when I execute the test I get:
"System.InvalidOperationException:
The path to the driver executable must be set by the webdriver.ie.driver system property; for m....."![enter image description here][1]
I'm running this one one machine both acting as a hub and a node just to make a proof of concept it'll work for me.
There are a number of things I'd question about your approach to what you're trying to accomplish. First, if you're running your C# code on the same machine as the remote Java server (node/hub), why bother? You can easily just use the InternetExplorerDriver class and eliminate the Java server altogether.
Second, setting an environment variable is not the same as setting a Java system property. You can set the system property by using a -D command line flag on the command line with which you launch the Java .jar.
Finally, if you're actually running the Java server on a different machine from the C# code, and are correctly using RemoteWebDriver, bear in mind that you need IEDriverServer.exe on the machine running the Java server, and not the one running your C# code. Furthermore, you need the hub/node to be aware of the path to the executable on that machine, not to the executable where your C# code is running.
I've got it solved, used the appropriate version IEDriver and fixed the PATH and it worked.
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'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.
Im deploying my website onto my new server (windows 2003) from my local pc (windows 7) and my local homeserver (windows 2008) and have run in to a issue.
I have a process that starts up with the below code. It is passed a video file which gets converted.
System.Diagnostics.ProcessStartInfo StartInfo = new System.Diagnostics.ProcessStartInfo(Command, Parameters);
Them problem I have is on my new windows 2003 server it fails to work. No error or anything. Looking at the server and its taskmgr.exe I see the Process start but nothing happens.
Looking into it, everyone seems to say I need to have impersonate="true" in the webconfig which I do have, I currently have it set to the Administrator account which I use to log into remote desktop (I assume this is fine???)
<identity impersonate="true" userName="Administrator" password="********" />
This still doesn't work.. Looking in the taskmgr.exe the process is started with the username ="NETWORK SERVICE" ...
Any ideas???
A concrete solution i can't provide, but maybe this can help:
Take a low level look with Process Monitor to find if it is security related (missing permissions etc.)
Build a Debug Version of your programm and insert some Debug.Print() statements to narrow the problem. These messages can be seen bei Debug Viewer.
Maybe it's a problem with a wrong or missing assembly. To find these problem take a look into the Fusion Log Viewer.
Maybe one of these techniques will help you to tackle down your problem.