My project includes a template that is installed in the 32 bit Program Files directory. Accessing this template is relatively simple:
string templateLoc = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
+ #"\path.html";
This works as intended on my local system, including after building the WiX installer. However, on my client's system, it looks for the template in the System32 directory.
The only real difference between our systems is that I run Windows 7, and my client runs Windows 10. Is there a difference between these systems that affects Environment? Or, is there something wrong with my syntax?
Related
I am developing an application .NET Core (dotnet) in C# that must run on Windows 10, Linux AND in the Linux subsystem that can be installed in Windows 10.
The problem is that the application must stored files in a common location to let other application use they. That is, others applications (that are clients) must resolved the same path as this application does. So, the same code must be added in all of the clients to know where the files are storage.
I searched a lot and I found this solution:
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData));
This returns me on Windows:
C:\ProgramData
And on Linux:
/usr/share
I like this solution but the problem here is that when the program is running in a Linux subsystem, I want to use a path that can be acceded from applications running on Windows natively.
I know that Windows is mounted in /mnt/c/ in the Linux subsystem but y dont want to have hardcoded paths.
Is there any way to have programatically (running on Linux subsystem) a path in the Windows host? That is, if the program run on Linux natively the path that returns is /usr/share BUT if it is a subsystem, the path that returns is /mnt/c/ProgramData (or something like that).
Thanks!
Our primary business application is written in a mixture of VB.NET and C# using VS2008. The back-end is SQL server Express 2005.
The application is NOT installed on client machines. It resides on a network share on (currently) a Windows Server 2003 machine which also hosts the database. Clients access the application through a shortcut, and there are additional server-side executables running as services which are accessed by the client application code. It's an entirely 32-bit environment at present.
We are moving to Server 2008 R2 and SQL Express 2008, and will be upgrading some of our 32-bit Win7 clients to 64-bit. I have set the Target CPU to "Any CPU" in the compile options of all .EXE and .DLL projects that comprise the application and have run PVerify on them all - they are entirely managed code.
Is this enough? Will both 32 and 64-bit clients be able to run the application seamlessly?
Thanks
The client applications should work in this configuration, assuming they are pure managed code as you say. You haven't said whether you've tested this or not, but testing shouldn't be all that hard. :-)
Note that 64-bit versions of Windows have the WoW64 subsystem that can run 32-bit applications, so you probably didn't have to do anything in the first place.
The question What does the Visual Studio “Any CPU” target mean? may be worth reading, but it looks like that is already understood here. If you need to be able to produce both x86 and x64 outputs (for example, if you have unmanaged DLLs that need to be called into), the question Targeting both 32bit and 64bit with Visual Studio in same solution/project may be useful.
Since I can't find anything clearly stating it on the MSDN documentation: what does the ProgramFilesX86 enum value return on 32-bit systems?
Development Environment
Please note: in my organization I can't just stand up machines whenever I want to test things. This is why I'm asking the community. I don't even have access to 32-bit ISO's to build a virtual machine -- so please understand I have some limitations inside this organization.
Windows 7 64-bit
Production Environment
In production I don't know if they are running 32 or 64-bit systems, and it's likely a mixture. However I do know the list of operating systems.
Windows 7
Windows Vista
Windows XP
Objective
Get the correct program files directory so I can launch my application dynamically.
Known Variables
The application is installed with an MSI, and it will be installed with the default options, so it will be installed in the Program Files directory.
The application is a 32-bit application, so on 64-bit systems it will use the Program Files (x86) folder, but on 32-bit systems it will use the standard Program Files directory.
Thanks all!
32-bit XP: an empty string :(
32-bit Vista: "C:\Program Files"
32-bit Win7: not tested, probably same as Vista
64-bit Win7: "C:\Program Files (x86)"
Not sure about 64-bit XP, I am curious myself.
The Remarks section for KNOWNFOLDERID contains a handy table giving you the information you seek (from an unmanaged perspective). It's tricky to reproduce it here:
OS App KNOWNFOLDERID Default CSIDL
32 bit 32 bit FOLDERID_ProgramFilesX86 %SystemDrive%\Program Files CSIDL_PROGRAM_FILESX86
64 bit 64 bit FOLDERID_ProgramFilesX86 %SystemDrive%\Program Files (x86) CSIDL_PROGRAM_FILESX86
64 bit 32 bit FOLDERID_ProgramFilesX86 %SystemDrive%\Program Files (x86) CSIDL_PROGRAM_FILESX86
It returns "Program Files". Since you're installing using an MSI, you might consider using the installer APIs (MsiLocateComponent, and so on) to locate your program instead of assuming it's in the expected location.
On my Win 7 32-bit system ProgramFilesX86 returns C:\Program Files (no trailing slash).
Console.WriteLine("GetFolderPath: {0}", Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86));
I made C# application for my friend which has connection to access database (mdb file). I have developed application on my computer with win7 x86 installed. My friend had XP and it worked perfectly, but now he installed win7 x64 and application doesn't work. In fact, application starts and behave regular, but cannot connect to database... Database too can be opened with access, but my application cannot connect to it.
What can be a problem? How to make my application works on both operating systems?
regards,
Vajda
Ask your friend to download and install the following file:
Microsoft Access Database Engine 2010 Redistributable
and make sure he picks the 64-bit version there (AccessDatabaseEngine_x64.exe).
By default there is no 64-bit ODBC/OLEDB driver for Access installed, but the 2010 version should work for 2007 databases as well.
You could probably also configure your program to be built for the x86 target. That would run the program as a 32-bit program, even on 64-bit OS.
Most likely, the .Net CLR is trying to fire the app up in 64bit mode by default on his new win7 box and this might be causing some issues with the referenced assemblies.
The first thing I would try is to change the Platform target of the application (go to Project properties in Visual Studio for the application) to x86 (from Any CPU) to force the application to run in 32bit mode.
If this works, you will have narrowed down your problem.
Then, after building the project, look in the bin folder to see which assemblies are being copied to the output folder. If you see any System.Data... or any other .Net assemblies that are already contained in the GAC, you'll want to delete these and then try to fire it up. This will force the application to use GAC assemblies written for 64bit use.
I have an application that is supposed to read from the Registry and when executing a console application my registry access works perfectly.
However when I move it over to a test this returns null:
var masterKey = Registry.LocalMachine.OpenSubKey("path_to_my_key");
So my question is:
Does Visual Studio run Tests with a less privileged process?
I tested to see what user this gave me: var x = WindowsIdentity.GetCurrent().Name; and it gives me the same as in the console application. So I am a bit confused here.
I am using MS Test Framework and the machine is Windows 2003 64 Bit.
It is not a security issue. It's the fact that you are running on a 64-bit operating system. 64-bit apps have a different view of HKLM\Software than 32-bit apps. 64-bit apps get the "normal" view, 32-bit apps are redirected to HKLM\Software\Wow6432Node. The EXE determines the bit-ness of the process, it will be different when mstest runs the code. 32-bit, probably.
You'll need to create the key you are trying to read in the Wow6432Node tree. Or make the regular app have the same bit-ness, Project + Properties, Build tab, Platform Target = x86. Also changeable on-the-fly with Corflags.exe.
I would say yes. Why do you expect anything different?
It would have to be this way to be Windows Logo compliant.
It's also good from a security viewpoint.
Visual Studio .NET is Windows Logo compliant, so you would expect that it runs as a restricted user
http://blogs.msdn.com/vcblog/archive/2006/09/06/742187.aspx