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
Related
Learning C# as I go along with managing an existing project given to me. I've noticed there seem to be deployment issues when I build from my windows 10 machine and set up the application on a user's Windows7 machine
Issues such as:
-Getting null pointer errors
-when saving word docs automatically, instead a save dialog box appears
I cannot for the life of me recreate the issues on my machine.
From what I see,
I use Windows 10 64bit with 32bit Microsoft Office
They use Windows 7 64bit with 32bit Microsoft office
We both have .NET v3, v3.5, v4.0.3... and the project is in v4
I can't help but think it is OS related issue I need to account for but I don't know whether I can trust this due to my lack of experience
Can anyone give some advice
My current plan is, since the users are not very accessible, I will try and get a laptop that replicates theirs. Then, if I can recreate the error on there, then i will install visual studio remote debugger and try to attach this external process and debug from my side. Mostly this is my only plan which is a long shot at best
It sounds like you're dealing with Office automation/addins. I would imagine that the version of Office is very important -- not just 32 bit vs 64 bit, but the specific build and version of Office/Word.
Recreating the error is key, as you suspect. Try setting up a Windows 7 VM on your PC with the same environment that the users have. This will make it easier for you to reproduce and debug the issue.
You also need to know the exact sequence of steps that causes the error, and if possible, you will need a copy of the document the user was working on.
I have just moved from a 32-bit Windows 7 desktop to a 64-bit Windows 7 Laptop. We have a C# program that we are developing that contains approximately 60 projects within the solution. I keep getting the following error whilst trying to build:
Attempt to load Oracle client libraries threw BadImageFormatException. This problem will occur when running in 64 bit mode with the 32 bit Oracle client components installed
Obviously the error is quite self explanatory and I am trying to get my whole solution to load in 32 bit mode. I have gone through every single project and set the target platform to x86 but I am still getting this error. I have searched Google and seen countless different approaches, but I cant seem to fix this problem. What is the best way to ensure my project is running in 32-bit mode on a 64-bit machine?
I am using Visual Studio 2008. I am currently considering downgrading to 32-bit but really want to avoid having to do this.
I found that you have to install the 32-bit Oracle client (you can download the installer from their website) even if you are running on a 64-bit machine.
In addition, during the discussions people were talking about 32-bit mode etc. This is how you can check / set that for an IIS 7 hosted application. You shouldn't need to change this but I have added here for completeness / future reference.
Launch IIS 7 and expand the server name node.
Click on Application Pools node and find the
application Pool you are using.
On the right-hand panel click Advanced Settings...
In the pop-up box that appears check Enabled 32-Bit Applications setting which is third option from the top.
You have to change your main .exe file to run only as 32-bit. You can do this in Visual Studio - just change Platform target from "Any CPU" to "x86".
If this is not possible, use corflags.exe which forces an existing exe to be a 32-bit application.
I have been struggling with this issue for months now and finally solved it. I think all the posts are helpful, but I had one missing piece. I didn't have a Microsoft ODBC for Oracle instance setup for User DSN or System DSN. I'm working on a Windows 8 machine. So for me I had to go to the general windows search and type in ODBC and open the ODBC Data Source Administrator (32-bit). Check to see if you have a Microsoft ODBC for Oracle setup on the User DSN tab or the System DSN tab. If not click on Add and select Microsoft ODBC for Oracle. Fill out the info for your datasource you are trying to hit and click ok. Make sure to restart your computer and that is what finally worked for me. Hope this helps some of you.
You have to change your main .exe file to run only as 32-bit. You can do this in Visual Studio - just change Platform target from "Any CPU" to "x86".
https://msdn.microsoft.com/en-us/library/ms185328.aspx
In my case 64 bit Oracle client was installed on my machine but still giving same error. So, I have analyse that in my application go to Application right click go to ->Properties->Web tab
and uncheck the "Use IIS Express" option if you are using local IIS Web server.
Problem got solved.
First of all, yes, I was searching about this topic around the internet, but my case is a little more specific, so this is the reason of my question.
My app is an executable winform app developed in Visual Studio .NET 2005 with Framework 2.0, C#
The app needs run some commands on a command line. This command must run as administrator.
The code that actually works is:
string output = "";
Process Consola = new Process();
ProcessStartInfo ConsolaStartInfo = new ProcessStartInfo();
ConsolaStartInfo.FileName = "cmd.exe";
ConsolaStartInfo.WorkingDirectory = System.Environment.SystemDirectory;
ConsolaStartInfo.UseShellExecute = !NeedOutput;
ConsolaStartInfo.RedirectStandardOutput = NeedOutput;
Consola.StartInfo = ConsolaStartInfo;
ConsolaStartInfo.WindowStyle = ProcessWindowStyle.Hidden;
ConsolaStartInfo.CreateNoWindow = true;
ConsolaStartInfo.Arguments = "/C " + CommandToPerform;
ConsolaStartInfo.Verb = "runas";
Consola.Start();
Consola.WaitForExit();
where:
CommandToPerform is a string var with a command
NeedOutput is true or false depending if i need a return output or not.
(This works)
The first tip is: this application works perfectly as is expected if I'm running the Visual Studio as administrator on Windows 7.
The second tip is: this application works perfectly as is expected if I'm running the Visual Studio NOT as administrator, but everytime the command line is executed, the process ask me for security validation on the screen (UAC)
Yes, I tried to work with the manifest but I've a lot of problems to compile it. It returns 9009 error sometimes, a lot of kind of errors.
So my questions are:
1) There's possible to do that without ask to the user for permissions? The application must be silent. This is the real question. If so...
2) How can I define the manifest for my application runs this command as administrator? I miss anything about? It's the same sign the application?
3) Can My app runs these commands as administrator without running as administrator? This is the perfect scenario, the users that will use this app can't be / can't will be administrators.
4) This will work on XP? XP ask for UAC? (I can't test it on XP until I develop a minimal requirement version)
Any kind of idea / solution / tip will be appreciated, and if on the final is not a solution, the better workaround will be mark as answer (I've a 100% rate)
Notes:
I can't migrate the framework from 2.0 to an above edition by client requirement.
I can't migrate the Visual Studio .NET 2005 to an above edition by client requirement.
The applications needs run for all editions from XP (without any SP) to Windows 7
Yes, I can use a workaround IF is under "Microsoft Policy" and app requirements (Framework 2.0, API or something like, mods/controls/library that are NOT from microsoft can NOT be used)
EDITED:
The solution of adding a key to: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers WORKED.
But when you run the application, it's prompt (with the common UAC prompt) for permissions
Well the answers to questions 1) and 3) are simple: this is impossible. Because if it were possible, the whole UAC would have no use at all.
I don't know about XP compatibility (but I do think XP will ignore the manifest) and unfortunately I have no experience with the UAC prompt and VS2005 either. I only did this in VS2008 and above, so I can't help there either. I did find a guide for VS2005, but it's likely you have seen the same one as well:
Enabling your application for uac on vista.
It can be done doing a little service that runs the command, and the service process installer must be with the property Account on: LocalSystem.
So your application doesn't need any requirement or manifest.
It's working on Win7 and on XP
MSDN Creating a Windows Service
And the note:
The LocalSystem account has broad permissions, including the ability
to write to the event log. Use this account with caution, because it
might increase your risk of attacks from malicious software. For other
tasks, consider using the LocalService account, which acts as a
non-privileged user on the local computer and presents anonymous
credentials to any remote server.
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'm updating my operating system to Windows 7 x64, I only have experience with running 32-bit operating systems. Does anyone have any bad/good experiences with a 64 bit environment?
For reference, the tools I use are:
Visual Studio 2008
Tortoise SVN
TestDriven.Net
Oracle 10g XE
PL/SQL Developer
Dundas Chart
Analysis Services from MS SQL Server 2008
Running on a 64-bit operating system has a number of side effects that will be noticeable to some extent. The most common issues:
Edit and Continue in Visual Studio won't work. You can fix this by forcing your .NET app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86. Resolved in VS2013.
If you use any ActiveX controls or COM components in your .NET app you may find your program no longer works since your machine doesn't have a corresponding 64-bit version of the COM server. You'll get error 0x80040154, REGDB_E_CLASSNOTREG, "Class not registered". Same fix as above.
The 64-bit debugger doesn't support mixed-mode debugging, you'll have to commit to either Managed only or Native only debugging. Same fix as above, as long as you don't have 64-bit specific issues. Resolved in VS2010.
Poorly written P/Invoke declarations that declare an uint or int where an IntPtr is required will stop working in 64-bit mode. You'll generally get an AccessViolation exception or a failure return code. Or a PInvokeStackImbalance MDA warning. You should not have any trouble locating the mistake, just fix the declaration.
Several legacy end-of-life Microsoft libraries are not available in a 64-bit version. That's most commonly a problem with Microsoft Access databases. Same fix as above.
You must use the correct version of Regasm.exe to register [ComVisible] assemblies. Select the one from either Framework or Framework64, depending on whether the client program is going to run in 64-bit or 32-bit mode. Or both if you want the server to be available in either.
A few COM type libraries contain bit-ness dependent arguments in their method declarations. ADO 2.8 is a notable one. Be sure to use the correct bitness of Tlbimp.exe to generate the correct COM interop assembly, Visual Studio won't do this right. Same approach as Regasm.exe
A 32-bit program has a different view of the registry from a 64-bit program. Specifically the HKCR and HKLM\Software hives are virtualized. In Regedit.exe, the 32-bit visible keys are seen under the HKLM\Software\Wow6432Node key. This can cause many subtle problems with programs that use the registry. The .NET 4 RegistryKey.OpenBaseKey() allows specifying the view you want.
Again for COM, you'll have the use the correct bitness of Regsvr32.exe to register an unmanaged COM server (not .NET servers, they use Regasm.exe). Use the one in c:\windows\system32 for 64-bit servers, c:\windows\syswow64 for 32-bit servers.
Folders in the file system are virtualized, specifically c:\windows\system32 and c:\program files. A 32-bit program will see c:\windows\syswow64 and c:\program files (x86).
Installers need to take all the above issues in consideration.
I wouldn't worry too much, if each program has an x64 download link, then use that. If not then your code will run through WOW64 emulation. And it will seem to you like it is running like normal.
Please see this related question I answered about 5 minutes ago.
WOW64 refers to windows32 on windows64
and it is a transparent emulation
laywer that allows x86 programs to run
on x64 operating systems. WOW64 will
automatically be used if you run an
x86 Windows program on an x64 Windows
operating system.
I am running Windows 7 Ultimate x64.
Visual Studio 2008 works fine.
I am using Subversion, but not Tortoise. AnkhSVN works fine.
The others I have no experience with.
Majority of software I use has no issues with x64, it's been a few years since the XP x64 troubles, and people have caught up with x64 it seems.
The primary issue with development in x64 however, is when running in x64 mode in Visual Studio, you can not edit code while debugging.
You must use x86 as the target platform in order to do so.
This is one of the reasons one of the beta's for Visual Studio 2010 defaulted target platform to x32 instead of Any Platform...