I've created a WPF Window with a lot of buttons, each of them run a different program. To run MS Word, for instance, I used:
System.Diagnostics.Process.Start("C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE");
But when I try to run the Windows 7 Snipping Tool the same way it doesn't work. It was supposed to be like this:
System.Diagnostics.Process.Start("C:\\Windows\\System32\\SnippingTool.exe");
I'm sure the path is correct, but always appears a message saying the file wasn't found. I would like to know why is this happening.
Important: I use Windows 7 64 bits.
Use this:
// if the build platform of this app is x86 use C:\windows\sysnative
if(!Environment.Is64BitProcess)
System.Diagnostics.Process.Start("C:\\Windows\\sysnative\\SnippingTool.exe");
else
System.Diagnostics.Process.Start("C:\\Windows\\system32\\SnippingTool.exe");
The problem is in your build platform (x86) and the automatic redirection of the folder C:\Windows\System32\ on 64-bit OS'es.
Basically, for several reasons, in vista/windows 7 64-bit OS'es when a 32 bit application try to access to C:\Windows\System32\ it is automatically redirected to the folder called C:\Windows\SysWOW64\. Hence, you cannot start snippingtool.exe because it is not present in that folder.
The only way is to use C:\Windows\sysnative\ and bypass the redirection.
My psychic debugger tells me that you are running a 32-bit program on a 64-bit version of
Windows, so your call to %WINDIR% (C:\Windows) is actually being re-routed to C:\Windows\SysWOW64.
Use the environment variable instead of hard-coding paths to directories that may move around depending on the environment and/or Windows version..
You should use an environment variable instead. Likely you are running it on a 64 bit system and C:\Windows\System32\ is getting redirected.
Related
I noticed that some of the newer Windows 10 exe applications don't start using System.Diagnostics.Start() method. For Example:
System.Diagnostics.Start(#"C:\Windows\System32\StikyNot.exe")?
However Older Windows exe's will start:
System.Diagnostics.Start(#"C:\Windows\System32\notepad.exe")?
and others such as Calc.exe in Windows 10 are lost and mixed up in "metro random string id land" and have a way to provide a real file system path to execute them from System.Diagnostics.Start().
But, Specifically, I want to know why "StikyNot.exe" doesn't work from Start() and how to launch this application from c#? For, its just says that the file is missing, but clearly it is there when you type "dir C:\Windows\System32\StikyNot.exe" from cmd.exe.
(Also, I'm using Windows 10 straight from the install CD-ROM without installing any updates.)
I have a simple application using a product activation system offered by cryptlex (cryptlex.com).
The program works correctly on my computer, but when I try to run the program on another machine it returns this error:
I've already made sure that the dll is inside the executable folder and everything looks OK.
When I remove all part of cryptlex the program works perfectly on any machine (x86-x64)
I used depencywalker to check for errors and found these two in the executable that uses cryptlex:
Windows 7 64bits,
.NET Version: 4.0
You can use Process Monitor to record all file activities of the program. Set a filter for your executable. After reproducing the error, save the log as XML file.
Then run ProcMon Analyzer (note: I'm the author of it). It will analyze the file and give a list of DLLs that were not found.
You could also do that manually, but note that some DLLs may not be found at first, but later be found when looking in the %PATH% environment variable etc. The tool will remove all those entries which have PATH NOT FOUND first but SUCCESS later.
While the DLL is present, have you checked the bitrate?
Most C# projects default to building against Any CPU - if the DLL is specific to a bitrate (ie x86 or x64) then it might be that the program picks the wrong bitrate on end machines (usually x86) but the right one on your machine (x64). This is usually best resolved by building out different x86 and x64 versions; it's messier, but only .NET itself is good at using the Any CPU paradigm.
The exception should have detail about what DLL in particular was not found - maybe look closer?
GPSVC and IESHIMS missing should not be a problem; as indicated by the hour glass, they're deferred dependencies anyway.
I'll prefix this question with: No, Setting IRONPYTHONPATH is not the answer.
Anyway...
I was planning on using IronPython as a replacement for Powershell for a project, but I've been stumped before I've even started.
The very first thing I tried to do was use os.path, resulting in:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named os
After messing around I finally discovered I could use the standard library by adding it manually to the path:
import sys
sys.path.append(r"C:\Program Files\IronPython 2.7\Lib")
import os
However, this is a daft idea. Hard coding the path to the python library inside my scripts is a 100% guaranteed way of making them not work at some point.
I discovered this almost immediately when I tried to use the script on a windows 7 machine and the path was slightly different ('Program Files (x86)').
So, a couple of questions here:
1) Why is it so hard to use the standard library? At the very least I would have thought the interactive prompt in VS and basic ipy.exe would have this.
2) How can I determine the directory that iron python is installed in regardless of the system I'm using? (IronPython installer setting a var perhaps?)
Just a note here; yes, I have seen some other posts saying "set your IRONPYTHONPATH". This in unhelpful. If I have a blank machine that means I have to:
1) Install IronPython
2) Run some crazy powershell script to search out where-ever-the-heck the standard library was installed and set a global IRONPYTHONPATH variable to it.
3) Run python scripts
I'm looking for a better way.
--
Edit:
The fact I'm using this to do powershell like things is basically irrelevant, but I'm trying to achieve something like:
import clr
from System.Management.Automation import RunspaceInvoke
import os
scriptRoot = os.getcwd()
runSpace = RunspaceInvoke()
cmdPath64 = os.join(scriptRoot, "..\java\...")
cmdPath32 = os.join(scriptRoot, "..\java\...")
proc = runSpace.Invoke("Get-WmiObject Win32_Processor ... ")
if proc.AddressWidth == 32:
runSpace.Invoke(cmdPath32)
else:
runSpace.Invoke(cmdPath64)
I find that for ensuring that everything works for non-developer third parties, it's usually better to use pyc.py to create DLL's and and executable. I routinely create a DLL of the python standard modules and reference that in code. See my previous answer at this question IronPython: EXE compiled using pyc.py cannot import module "os"
It's a bit workaroundish but, given that the LIB directory of ironpython is installed under the x86 program files folder in 64bit systems and on the usual program files path on 32bit systems, you could do in this way:
import sys
import System
if System.IntPtr.Size * 8 == 32: # detect if we are running on 32bit process
sys.path.append(System.Environment.GetEnvironmentVariable("ProgramFiles") + "\IronPython 2.7\Lib")
else:
sys.path.append(System.Environment.GetEnvironmentVariable("ProgramFiles(x86)") + "\IronPython 2.7\Lib")
import os # it works !!
Here we use %ProgramFiles% and %ProgramFiles(x86)% to determine the path where IronPython is installed.
Quoting wikipedia about %ProgramFiles% variable (link):
%ProgramFiles%
This variable points to Program Files directory, which stores all the
installed program of Windows and others. The default on
English-language systems is C:\Program Files. In 64-bit editions of
Windows (XP, 2003, Vista), there are also %ProgramFiles(x86)% which
defaults to C:\Program Files (x86) and %ProgramW6432% which defaults
to C:\Program Files. The %ProgramFiles% itself depends on whether the
process requesting the environment variable is itself 32-bit or 64-bit
(this is caused by Windows-on-Windows 64-bit redirection).
This is very odd, because if you run the the IronPython installer, and then run C:\Program Files\IronPython 2.7\ipy.exe or C:\Program Files (x86)\IronPython 2.7\ipy.exe, you shouldn't need to do anything to have the stdlib available.
My guess is that you have more than one IronPython and you're running the wrong one, but only because I can't think of another reason this would happen. It's supposed to Just Work.
I am trying to use the TaskDialog but encountering some problems:
I am getting the following error:
Error 1 Could not find file
'Microsoft.Windows.Common-Controls,
Version=6.0.0.0, Culture=*,
PublicKeyToken=6595b64144ccf1df,
ProcessorArchitecture=X86,
Type=win32'. WpfApplicationUnleashed
I have changed my manifest file to as per this link
http://www.nbdtech.com/Blog/archive/2008/06/16/The-Application-Manifest-Needed-for-XP-and-Vista-Style-File.aspx
2) If I use this TaskDialog, I will see if the OS running is windows vista or higher and selectively use/ dont use TaskDIalog, however, is there any difference in TaskDIalog in Vista and Windows 7.I mean will have to filter windows vista and windows 7 also ?
Are you running your app under the debugger? If so, try running it without the debugger i.e. press Ctrl+F5, or run it from Explorer. If it works without the debugger, then the problem is because of the Visual Studio hosting process, which is a special process which the debugger uses to host your real application when debugging to speed various things up.
To work around this, create a second copy of your manifest file called YourApp.vshost.exe.manifest in your project, and set it 'Copy to Output' to 'Copy if newer'.
I built an application in c# vs2005 .net .
Everything works fine when i run the application in win 32 bit, But
when running the application in win 64 it crashes while trying to call
the pinvoke interlockedexchange(which is within the kernel32.dll) function .
This is the exception :
unable to find an entry point named 'interlockedexchange'
I didnt find the interlockedexchange function within the kernel32.dll under system32 directory but it was found under the syswow64 directory(in the kernel32.dll) .
I guess that the .net runtime is configured to the system32 directory and not to the syswow64 .
How is it possible to change this configuration ? Can you think of any other problem that could cause this?
any help would be appreciated!
thanks ,
Miki Amit
If you are set on using InterlockedExchange and want the 32-bit version, you can change your project settings to force it to run as 32-bit. Go to the "Build" tab in the project settings and change "Platform target" to x86. It will then run as 32-bit.
This does not directly answer your question, but why not call System.Threading.Interlocked.Exhange() rather than resorting to P/Invoke?