I am going to open the photo viewer using .net core and this is my code
using System.Diagnostics;
namespace TestProcessForOpenPhoto
{
class Program
{
static void Main(string[] args)
{
var photoViewer = new Process();
photoViewer.StartInfo.FileName = #"C:\Program Files\Windows Photo Viewer\PhotoViewer.dll";
photoViewer.StartInfo.Arguments = #" C:\Users\XXXXX\Desktop\TestImage\abc.jpg";
photoViewer.StartInfo.UseShellExecute = false;
photoViewer.Start();
}
}
}
and I got this error message
System.ComponentModel.Win32Exception: 'The specified executable is not a valid application for this OS platform.'
Can anyone help me to fix this bug, thanks
After researching this I noticed folks using rundll32.exe to execute an export from PhotoViewer.dll to display a picture using Microsoft Photo Viewer application. So I think that's what OP was trying to do, they just forgot to use the rundll32.exe application.
So I thought I'd take a crack at this and not use the rundll32.exe and just call the export directly. I debugged it with x86dbg and saw that it's passing in 4 parameters: pointer, pointer, pointer (to wchar_t*), int. I don't know what the parameters do, so I just set them to NULL and made sure to pass in the path to the picture as the 3rd and it seems to work.
So this will do what you want it to do. I know that hard-coding system paths is bad practice, but maybe someone who has more time can make this more dynamic.
private static class WindowsPhotoViewer
{
private const string FilePath32 = #"c:\program files (x86)\Windows Photo Viewer\PhotoViewer.dll";
private const string FilePath64 = #"c:\program files\Windows Photo Viewer\PhotoViewer.dll";
[DllImport(FilePath32, CharSet = CharSet.Unicode, EntryPoint = "ImageView_FullscreenW")]
private static extern void ImageView_Fullscreen32(
IntPtr unknown1, IntPtr unknown2, string path, int unknown3);
[DllImport(FilePath64, CharSet = CharSet.Unicode, EntryPoint = "ImageView_FullscreenW")]
private static extern void ImageView_Fullscreen64(
IntPtr unknown1, IntPtr unknown2, string path, int unknown3);
public static bool ShowImage(FileInfo imageFile)
{
if ((IntPtr.Size == 8) && File.Exists(FilePath64) && imageFile.Exists)
{
ImageView_Fullscreen64(IntPtr.Zero, IntPtr.Zero, imageFile.FullName, 0);
return true;
}
else if ((IntPtr.Size == 4) && File.Exists(FilePath32) && imageFile.Exists)
{
ImageView_Fullscreen32(IntPtr.Zero, IntPtr.Zero, imageFile.FullName, 0);
return true;
}
return false;
}
}
Then you can call it as so:
if(!WindowsPhotoViewer.ShowImage(new FileInfo(#"c:\users\andy\desktop\test.jpg")))
{
Console.WriteLine("Failed to show image");
}
Is there an analog of the SetFileSecurity function?
I need to re-write some tests from Python and I'm stuck on this part. In Python I can freely edit a DACL with pywin32 (modules with a C++ implementation to work with Windows API).
I can edit any ACE with win32security.
Change owner to Everyone? Okay.
win32security.SetNamedSecurityInfo("somefile.txt", win32security.SE_FILE_OBJECT,
win32security.OWNER_SECURITY_INFORMATION,
win32security.ConvertStringSidToSid("S-1-1-0"))
sd.SetSecurityDescriptorDacl(1, dacl, 0)
win32security.SetFileSecurity(filename, win32security.DACL_SECURITY_INFORMATION, sd)
Remove an inherited ACE? Easy.
sd = win32security.GetFileSecurity("", win32security.DACL_SECURITY_INFORMATION)
dacl = SECURITY_DESCRIPTOR.GetSecurityDescriptorDacl()
dacl.DeleteAce(0)
sd.SetSecurityDescriptorDacl(1, dacl, 0) # may not be necessary
win32security.SetFileSecurity(filename, win32security.DACL_SECURITY_INFORMATION, sd)
And all of those without some special permissions.
But if I want to do something like this in C#. One way I found is changing a security descriptor with pure SDDL, but using System.Security.File.SetAccessControl() with FileSecurity doesn't work if SetSecurityDescriptorSddlForm was called without the SeSecurityPrivilege privilege. Also, even using an administrator token with nearly all privileges, if I want to change something in a "wrong" way (delete some inherited ACEs), the security descriptor doesn't apply. If I try to do something "very wrong", like set the owner to Everyone, an exception will be thrown.
var sddl_everyone_owner = #"O:S-1-1-0G:DUD:P";
var path = #"C:\Users\someuser\test.txt";
FileSecurity fs_edit = new FileSecurity();
fs_edit.SetSecurityDescriptorSddlForm(sddl_everyone_owner);
File.SetAccessControl(path, fs_edit);
Run with administrator token:
Unhandled Exception: System.InvalidOperationException: The security identifier is not
allowed to be the owner of this object.
at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle
handle,
AccessControlSections includeSections, Object exceptionContext)
at System.Security.AccessControl.NativeObjectSecurity.Persist(String name,
AccessControlSections includeSections, Object exceptionContext)
at System.Security.AccessControl.NativeObjectSecurity.Persist(String name,
AccessControlSections includeSections)
at System.Security.AccessControl.FileSystemSecurity.Persist(String fullPath)
at System.IO.File.SetAccessControl(String path, FileSecurity fileSecurity)
at rtest.Program.Main(String[] args) in C:\somepath\Program.cs:line 52
After 11 hours of googling, then trying to write some woking code i have this:
// changes SDDL of file:
using System;
using System.Runtime.InteropServices; // DllImport
public class SomeClass
{
[DllImport("Advapi32.dll", SetLastError = true)]
static extern void SetFileSecurity(string path, int type_of_sd, IntPtr sd);
[DllImport("Advapi32.dll", SetLastError = true)]
static extern bool ConvertStringSecurityDescriptorToSecurityDescriptor(string StringSecurityDescriptor, uint StringSDRevision, out IntPtr SecurityDescriptor, out UIntPtr SecurityDescriptorSize);
private static void Main()
{
string path = #"C:\Some\path\to\file";
string sddl = "D:AI(A;ID;FA;;;S-1-1-0)"; // set only one ACE: inherited full access to Everyone
uint sd_revision = 1; // the only revision of SECURITY_DESCRIPTOR
int DACL_SECURITY_INFORMATION = 4; // can be changed to change other properties, not DACL, relying on SECURITY_DESCRIPTOR_CONTROL parameters https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa379566%28v=vs.85%29.aspx
IntPtr sd_ptr = new IntPtr();
UIntPtr sd_size_ptr = new UIntPtr();
ConvertStringSecurityDescriptorToSecurityDescriptor(sddl, sd_revision, out sd_ptr, out sd_size_ptr);
SetFileSecurity(path, DACL_SECURITY_INFORMATION, sd_ptr);
}
}
This code import functions from Advapi32.dll right to C# code.
Special thanks to PInvoke.net!
Added this code to code samples.
You can get the sddl of a file or folder (symlink/junction) using the powershell command: get-acl -path "c:\some\file_or_folder" | fl.
Piping the output to fl translates the acl to both verbose list and ssdl form.
For the folder "C:\Users\someuser\Application Data" the sddl is
O:SYG:SYD:AI(D;;CC;;;WD)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;S-1-5-21-2614944367-2017529714-1376493066-1XXX)
or
O:SY Owner:NT Authority/System
G:SY Group:NT Authority/System
D:AI(D;;CC;;;WD)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;S-1-5-21-2614944367-2017529714-1376493066-1XXX)
"D:" means DACL
"AI" means something like Allow Inheritance
Each substring within parentheses is an Access Control Entry (ACE). Each ACE contains six fields delimited by semicolons that indicate the actual permissions. The first ACE, (D;;CC;;;WD), corresponds to the verbose list line: Everyone Deny ReadData. That is, D means Deny, CC means ReadData, and WD means Everyone. Note that the CC code as shown in Microsoft documentation is synonymous with SDDL_CREATE_CHILD in Sddl.h and the access right value ADS_RIGHT_DS_CREATE_CHILD. How CC is interpreted to mean "ReadData" isn't clear. Note also that specifying "Everyone" is done with the code WD (probably derived from "World"), not with a SID.
For those who wish to delve deeper please see https://learn.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format
https://learn.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language-for-conditional-aces-
https://learn.microsoft.com/en-us/windows/win32/secauthz/ace-strings
Good luck!
How do I find the application's path in a console application?
In Windows Forms, I can use Application.StartupPath to find the current path, but this doesn't seem to be available in a console application.
System.Reflection.Assembly.GetExecutingAssembly().Location1
Combine that with System.IO.Path.GetDirectoryName if all you want is the directory.
1As per Mr.Mindor's comment:
System.Reflection.Assembly.GetExecutingAssembly().Location returns where the executing assembly is currently located, which may or may not be where the assembly is located when not executing. In the case of shadow copying assemblies, you will get a path in a temp directory. System.Reflection.Assembly.GetExecutingAssembly().CodeBase will return the 'permanent' path of the assembly.
You can use the following code to get the current application directory.
AppDomain.CurrentDomain.BaseDirectory
You have two options for finding the directory of the application, which you choose will depend on your purpose.
// to get the location the assembly is executing from
//(not necessarily where the it normally resides on disk)
// in the case of the using shadow copies, for instance in NUnit tests,
// this will be in a temp directory.
string path = System.Reflection.Assembly.GetExecutingAssembly().Location;
//To get the location the assembly normally resides on disk or the install directory
string path = System.Reflection.Assembly.GetExecutingAssembly().CodeBase;
//once you have the path you get the directory with:
var directory = System.IO.Path.GetDirectoryName(path);
Probably a bit late but this is worth a mention:
Environment.GetCommandLineArgs()[0];
Or more correctly to get just the directory path:
System.IO.Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]);
Edit:
Quite a few people have pointed out that GetCommandLineArgs is not guaranteed to return the program name. See The first word on the command line is the program name only by convention. The article does state that "Although extremely few Windows programs use this quirk (I am not aware of any myself)". So it is possible to 'spoof' GetCommandLineArgs, but we are talking about a console application. Console apps are usually quick and dirty. So this fits in with my KISS philosophy.
Edit
It seems, from feedback, that most of the other solutions don't work when you are using a unit testing system. This sort of makes sense as the executable item is not your application but the testing system. I have not checked this out - so I could be completely wrong. If this is so, I will delete this edit.
For anyone interested in asp.net web apps. Here are my results of 3 different methods
protected void Application_Start(object sender, EventArgs e)
{
string p1 = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
string p2 = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;
string p3 = this.Server.MapPath("");
Console.WriteLine("p1 = " + p1);
Console.WriteLine("p2 = " + p2);
Console.WriteLine("p3 = " + p3);
}
result
p1 = C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\a897dd66\ec73ff95\assembly\dl3\ff65202d\29daade3_5e84cc01
p2 = C:\inetpub\SBSPortal_staging\
p3 = C:\inetpub\SBSPortal_staging
the app is physically running from "C:\inetpub\SBSPortal_staging", so the first solution is definitely not appropriate for web apps.
The answer above was 90% of what I needed, but returned a Uri instead of a regular path for me.
As explained in the MSDN forums post, How to convert URI path to normal filepath?, I used the following:
// Get normal filepath of this assembly's permanent directory
var path = new Uri(
System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetExecutingAssembly().CodeBase)
).LocalPath;
If you are looking for a .NET Core compatible way, use
System.AppContext.BaseDirectory
This was introduced in .NET Framework 4.6 and .NET Core 1.0 (and .NET Standard 1.3). See: AppContext.BaseDirectory Property.
According to this page,
This is the prefered replacement for AppDomain.CurrentDomain.BaseDirectory in .NET Core
You may be looking to do this:
System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase)
you can use this one instead.
System.Environment.CurrentDirectory
For Console Applications, you can try this:
System.IO.Directory.GetCurrentDirectory();
Output (on my local machine):
c:\users\xxxxxxx\documents\visual studio 2012\Projects\ImageHandler\GetDir\bin\Debug
Or you can try (there's an additional backslash in the end):
AppDomain.CurrentDomain.BaseDirectory
Output:
c:\users\xxxxxxx\documents\visual studio 2012\Projects\ImageHandler\GetDir\bin\Debug\
I have used this code and get the solution.
AppDomain.CurrentDomain.BaseDirectory
Following line will give you an application path:
var applicationPath = Path.GetDirectoryName(Process.GetCurrentProcess().MainModule.FileName)
Above solution is working properly in the following situations:
simple app
in another domain where Assembly.GetEntryAssembly() would return null
DLL is loaded from Embedded resources as a byte array and loaded to AppDomain as Assembly.Load(byteArrayOfEmbeddedDll)
with Mono's mkbundle bundles (no other methods work)
You can simply add to your project references System.Windows.Forms and then use the System.Windows.Forms.Application.StartupPath as usual .
So, not need for more complicated methods or using the reflection.
I have used
System.AppDomain.CurrentDomain.BaseDirectory
when I want to find a path relative to an applications folder. This works for both ASP.Net and winform applications. It also does not require any reference to System.Web assemblies.
I mean, why not a p/invoke method?
using System;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
public class AppInfo
{
[DllImport("kernel32.dll", CharSet = CharSet.Auto, ExactSpelling = false)]
private static extern int GetModuleFileName(HandleRef hModule, StringBuilder buffer, int length);
private static HandleRef NullHandleRef = new HandleRef(null, IntPtr.Zero);
public static string StartupPath
{
get
{
StringBuilder stringBuilder = new StringBuilder(260);
GetModuleFileName(NullHandleRef, stringBuilder, stringBuilder.Capacity);
return Path.GetDirectoryName(stringBuilder.ToString());
}
}
}
You would use it just like the Application.StartupPath:
Console.WriteLine("The path to this executable is: " + AppInfo.StartupPath + "\\" + System.Diagnostics.Process.GetCurrentProcess().ProcessName + ".exe");
Assembly.GetEntryAssembly().Location or Assembly.GetExecutingAssembly().Location
Use in combination with System.IO.Path.GetDirectoryName() to get only the directory.
The paths from GetEntryAssembly() and GetExecutingAssembly() can be different, even though for most cases the directory will be the same.
With GetEntryAssembly() you have to be aware that this can return null if the entry module is unmanaged (ie C++ or VB6 executable). In those cases it is possible to use GetModuleFileName from the Win32 API:
[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
public static extern int GetModuleFileName(HandleRef hModule, StringBuilder buffer, int length);
I use this if the exe is supposed to be called by double clicking it
var thisPath = System.IO.Directory.GetCurrentDirectory();
in VB.net
My.Application.Info.DirectoryPath
works for me (Application Type: Class Library). Not sure about C#...
Returns the path w/o Filename as string
I didn't see anyone convert the LocalPath provided by .Net Core reflection into a usable System.IO path so here's my version.
public static string GetApplicationRoot()
{
var exePath = new Uri(System.Reflection.
Assembly.GetExecutingAssembly().CodeBase).LocalPath;
return new FileInfo(exePath).DirectoryName;
}
This will return the full C:\\xxx\\xxx formatted path to where your code is.
AppDomain.CurrentDomain.BaseDirectory
Will resolve the issue to refer the 3rd party reference files with installation packages.
With .NET Core 3 and above you will get the .dll and not the .exe file. To get the .exe file path you can use.
var appExePath = Process.GetCurrentProcess().MainModule.FileName;
Try this simple line of code:
string exePath = Path.GetDirectoryName( Application.ExecutablePath);
For .NET 6 there's Environment.ProcessPath.
See https://learn.microsoft.com/en-us/dotnet/api/system.environment.processpath?view=net-6.0
None of these methods work in special cases like using a symbolic link to the exe, they will return the location of the link not the actual exe.
So can use QueryFullProcessImageName to get around that:
using System;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Diagnostics;
internal static class NativeMethods
{
[DllImport("kernel32.dll", SetLastError = true)]
internal static extern bool QueryFullProcessImageName([In]IntPtr hProcess, [In]int dwFlags, [Out]StringBuilder lpExeName, ref int lpdwSize);
[DllImport("kernel32.dll", SetLastError = true)]
internal static extern IntPtr OpenProcess(
UInt32 dwDesiredAccess,
[MarshalAs(UnmanagedType.Bool)]
Boolean bInheritHandle,
Int32 dwProcessId
);
}
public static class utils
{
private const UInt32 PROCESS_QUERY_INFORMATION = 0x400;
private const UInt32 PROCESS_VM_READ = 0x010;
public static string getfolder()
{
Int32 pid = Process.GetCurrentProcess().Id;
int capacity = 2000;
StringBuilder sb = new StringBuilder(capacity);
IntPtr proc;
if ((proc = NativeMethods.OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, false, pid)) == IntPtr.Zero)
return "";
NativeMethods.QueryFullProcessImageName(proc, 0, sb, ref capacity);
string fullPath = sb.ToString(0, capacity);
return Path.GetDirectoryName(fullPath) + #"\";
}
}
Path.GetDirectoryName(System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName)
Is the only one that has worked for me in every case I have tried.
In .NET 6, my WPF app (<TargetFramework>net6.0-windows</TargetFramework>) returns the .dll file path for Assembly.GetEntryAssembly()!.Location instead of the .exe file. They introduced System.Environment.ProcessPath for this purpose:
var path = Environment.ProcessPath; // Note it may be null
Returns the path of the executable that started the currently executing process. Returns null when the path is not available.
See discussion for it here and here.
I use this for console + net 6
Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)
The techniques, and pitfalls, keep changing. The below assumes you're running a .NET 6 console app on linux (on win/mac the results will follow a similar pattern, just replace /usr/share/ and /home/username/ with the standard locations for your OS).
Demo:
Console.WriteLine("Path.GetDirectoryName(Process.GetCurrentProcess()?.MainModule?.FileName) = " + Path.GetDirectoryName(Process.GetCurrentProcess()?.MainModule?.FileName));
Console.WriteLine("Path.GetDirectoryName(Environment.ProcessPath) = " + Path.GetDirectoryName(Environment.ProcessPath));
Console.WriteLine("Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) = " + Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));
Console.WriteLine("typeof(SomeType).Assembly.Location = " + typeof(SomeType).Assembly.Location);
Console.WriteLine("Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]) = " + Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]));
Console.WriteLine("AppDomain.CurrentDomain.BaseDirectory = " + AppDomain.CurrentDomain.BaseDirectory);
Console.WriteLine("System.AppContext.BaseDirectory = " + System.AppContext.BaseDirectory);
Results:
Path.GetDirectoryName(Process.GetCurrentProcess()?.MainModule?.FileName) = /usr/share/dotnet
Path.GetDirectoryName(Environment.ProcessPath) = /usr/share/dotnet
Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) = /home/username/myproject/bin/Debug/net6.0
typeof(SomeType).Assembly.Location = /home/username/myproject/bin/Debug/net6.0
Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]) = /home/username/myproject/bin/Debug/net6.0
AppDomain.CurrentDomain.BaseDirectory = /home/username/myproject/bin/Debug/net6.0/
System.AppContext.BaseDirectory = /home/username/myproject/bin/Debug/net6.0/
Each approach has its own pros and cons - see the other answers to learn in which uses cases to use which approach.
I run my .NET 6 console app with dotnet myapp, so what works (reliably) for me is either of:
typeof(SomeType).Assembly.Location
// or
Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)
Here is a reliable solution that works with 32bit and 64bit applications.
Add these references:
using System.Diagnostics;
using System.Management;
Add this method to your project:
public static string GetProcessPath(int processId)
{
string MethodResult = "";
try
{
string Query = "SELECT ExecutablePath FROM Win32_Process WHERE ProcessId = " + processId;
using (ManagementObjectSearcher mos = new ManagementObjectSearcher(Query))
{
using (ManagementObjectCollection moc = mos.Get())
{
string ExecutablePath = (from mo in moc.Cast<ManagementObject>() select mo["ExecutablePath"]).First().ToString();
MethodResult = ExecutablePath;
}
}
}
catch //(Exception ex)
{
//ex.HandleException();
}
return MethodResult;
}
Now use it like so:
int RootProcessId = Process.GetCurrentProcess().Id;
GetProcessPath(RootProcessId);
Notice that if you know the id of the process, then this method will return the corresponding ExecutePath.
Extra, for those interested:
Process.GetProcesses()
...will give you an array of all the currently running processes, and...
Process.GetCurrentProcess()
...will give you the current process, along with their information e.g. Id, etc. and also limited control e.g. Kill, etc.*
You can create a folder name as Resources within the project using Solution Explorer,then you can paste a file within the Resources.
private void Form1_Load(object sender, EventArgs e) {
string appName = Environment.CurrentDirectory;
int l = appName.Length;
int h = appName.LastIndexOf("bin");
string ll = appName.Remove(h);
string g = ll + "Resources\\sample.txt";
System.Diagnostics.Process.Start(g);
}
I'm using the ExtractAssociatedIcon method to retrieve the icon for the file. My hope is to retrieve the same icon that a user would see in their explorer window.
public static Icon GetIcon(string fileName)
{
try
{
Icon icon = Icon.ExtractAssociatedIcon(fileName);
return icon;
}
catch
{
return null;
}
}
This works 99% of the time. However, if the user has linked to a file on a shared path, such as \\SOME_SERVER\my documents\this file.pdf it returns null. It falls through the "catch" with the error that the file path is not a valid path.
It is a valid URI (I've verified the file exists, is readable, etc.), but not a valid fully-qualified drive path with the X:\some\folder notation.
How can I get around this, if at all?
Thanks.
Re-UPDATE
Here's the solution I ended up with. It's much cleaner than the first update. Many thanks to Chris Haas, whose answer was a comment, and not a direct answer. If/when he makes it a direct answer, I will update this as such.
I still had to go down to a lower level and fetch the icon through C++ libraries, but the only library I needed is listed below:
#region Old-School method
[DllImport("shell32.dll")]
static extern IntPtr ExtractAssociatedIcon(IntPtr hInst,
StringBuilder lpIconPath, out ushort lpiIcon);
public static Icon GetIconOldSchool(string fileName)
{
ushort uicon;
StringBuilder strB = new StringBuilder(fileName);
IntPtr handle = ExtractAssociatedIcon(IntPtr.Zero, strB, out uicon);
Icon ico = Icon.FromHandle(handle);
return ico;
}
#endregion
Once I had defined the above method, the GetIcon() method becomes:
public static Icon GetIcon(string fileName)
{
try
{
Icon icon = Icon.ExtractAssociatedIcon(fileName);
return icon;
}
catch
{
try
{
Icon icon2 = GetIconOldSchool(fileName);
return icon2;
}
catch
{
return null;
}
}
}
(Comment turned into post - CTIP)
Check out the link here which eventually leads to P/Invoke.net with the following code:
[DllImport("shell32.dll")]
static extern IntPtr ExtractAssociatedIcon(IntPtr hInst, StringBuilder lpIconPath, out ushort lpiIcon);
[DllImport("shell32.dll")]
static extern IntPtr ExtractIcon(IntPtr hInst, string lpszExeFileName, int nIconIndex);
_
ushort uicon;
StringBuilder strB = new StringBuilder(YOUR_FILE_PATH);
IntPtr handle = ExtractAssociatedIcon(this.Handle, strB, out uicon);
Icon ico = Icon.FromHandle(handle);
return ico.ToBitmap();
I'm getting some serious weirdness using FileVersionInfo.GetVersionInfo() and was hoping somebody might be able to help.
The basics of the issue is that I am iterating through all the files in a folder calling GetVersionInfo() on each. There are about 300 files. This works ok for all but 2 of the files. For these DLLs I am getting comepletely incorrect info back from GetVersionInfo().
In order to eliminate all other variables, I extracted this call into a simple test app and it still got the same problem. However, if I built the test app as a Windows Application (it was a Console Application initially) then the data came back correct.
Just to clarify, the incorrect data coming back when running as a Console App is not simply null info like you would get if the file didn't contain version data. It contained reasonable data, but just the wrong data. It's as if it's reading it from a different file. I've looked for a file that contains matching version data, but can't find one.
Why is this simple call functioning differently if built as a Console Application rather than a Windows Application?
If anyone can help with this I would be very grateful.
Rgds,
Andy
-- Code Added
using System;
using System.Diagnostics;
namespace test
{
class Program
{
static void Main(string[] args)
{
string file = "C:\\ProblemFile.dll";
FileVersionInfo version = FileVersionInfo.GetVersionInfo(file);
string fileName = version.FileName;
string fileVersion = version.FileVersion;
Console.WriteLine(string.Format("{0} : {1}", fileName, fileVersion));
}
}
}
This behaviour seems weird indeed. Could it be that the Console application does not load the DLL from the same place as the WinForms application does? This would mean that GetVersionInfo uses some other API than just Win32 CreateFile (maybe going through some DLL resolver mechanism, side-by-side or whatever); remember that under the covers, version.dll will be executing your request, not the CLR itself.
Looking at FileVersionInfo through Reflector points in another direction yet:
public static unsafe FileVersionInfo GetVersionInfo(string fileName)
{
// ...
int fileVersionInfoSize = UnsafeNativeMethods.GetFileVersionInfoSize(fileName, out num);
FileVersionInfo info = new FileVersionInfo(fileName);
if (fileVersionInfoSize != 0)
{
byte[] buffer = new byte[fileVersionInfoSize];
fixed (byte* numRef = buffer)
{
IntPtr handle = new IntPtr((void*) numRef);
if (!UnsafeNativeMethods.GetFileVersionInfo(fileName, 0, fileVersionInfoSize, new HandleRef(null, handle)))
{
return info;
}
int varEntry = GetVarEntry(handle);
if (!info.GetVersionInfoForCodePage(handle, ConvertTo8DigitHex(varEntry)))
{
int[] numArray = new int[] { 0x40904b0, 0x40904e4, 0x4090000 };
foreach (int num4 in numArray)
{
if ((num4 != varEntry) && info.GetVersionInfoForCodePage(handle, ConvertTo8DigitHex(num4)))
{
return info;
}
}
}
}
}
return info;
}
As you can see there, some interesting dance is going on with code pages. What if the DLLs you inspected had several version information resources attached to them? Depending on the culture of the program calling into GetVersionInfo, I guess that the code page related calls could return other results?
Take the time to check the resources of the DLLs and make sure that there is only one language/code page for the version information. It might point you at the solution, I hope.
Sure the "files" you're seeing aren't . and .. ? If you iterate through all files, you'll always see entries for . (current dir) and .. (up dir). GetVersion Info might well return anything for these. You'd have to filter these entries out manually by name.
File and Assembly versions are 2 different things.
Are you sure you are not expecting the other?
Update: Tried this. Didn't work.
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
namespace test
{
class Program
{
[DllImport("COMCTL32")]
private static extern int InitCommonControls(int nExitCode);
static void Main(string[] args)
{
InitCommonControls(0);
string file = "C:\\ProblemFile.dll";
FileVersionInfo version = FileVersionInfo.GetVersionInfo(file);
string fileName = version.FileName;
string fileVersion = version.FileVersion;
Console.WriteLine(string.Format("{0} : {1}", fileName, fileVersion));
}
}
}