I succeed to share folder in WinXP and Win7 (Using this method)
But I have a problem, when I'm trying to share a folder using Win8.
It gives me an error and says that I have to run an .exe file as administrator.
If your original program is not running Elevated and you want to start an application elevated (As Admin) you will have to do something like this (this will prompt for elevation):
Dim procStartInfo As New ProcessStartInfo
Dim procExecuting As New Process
With procStartInfo
.UseShellExecute = True
.FileName = "FileName.exe"
.WindowStyle = ProcessWindowStyle.Normal
.Verb = "runas" 'add this to prompt for elevation
End With
procExecuting = Process.Start(procStartInfo)
You need to change you application manifest so that it will only run as an administrator.
Application Properties>Application Tab>View Windows Settings
Then change this line to requireAdministrator
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
See this for more information: http://msdn.microsoft.com/en-us/library/vstudio/tzdks800(v=vs.120).aspx
Also see this SO question on the same topic: How do I force my .NET application to run as administrator?
Related
I'm trying to run an external program with some arguments (visual basic) and it was running all fine when executed from Visual studio Debug, but when using Release from visual studio or the published version(debug or release) there are no windows and the processes are running in Task Manager.
I tried this to modify the workingdirectory and windowstyle ProcessStartInfo properties with no results, that solved the similar cases asked here. In the task manager the opened program seems to stay "Under" my program in hiearchy vs when executed from VS ( not sure if that helps)
Dim startinfo As New ProcessStartInfo()
startinfo.FileName = slicerexepath
startinfo.WorkingDirectory = System.IO.Path.GetDirectoryName(slicerexepath)
startinfo.Arguments = arglist
startinfo.WindowStyle = ProcessWindowStyle.Normal
Process.Start(startinfo)
Cross check your "slicerexepath" is same for debug and release modes . In usual practice, release and debug exe are kept in separate path .
At work we are constantly juggling multiple licenses of a software package. The license key is stored in the registry in HKEY_LOCAL_MACHINE so I wrote a Windows Batch File that when run as administrator, edits the registry key to one of the license strings.
Most recently I've written a GUI based application in VB.net that uses the software package's API to add some cool functionality. I also wanted to include a GUI based license switching module to make the juggling even easier. However, I haven't been able to succeed in doing so.
I've tried multiple methods, running the program as Administrator:
Using VB.Net's Registry module
Dim key As RegistryKey = Registry.LocalMachine
Dim autoshell As RegistryKey
autoshell = key.OpenSubKey(registryKeyDirectory, True)
autoshell.SetValue("Software", licenseKey)
autoshell.Close()
Running a .reg script
Dim p As New ProcessStartInfo
p.FileName = "regedit.exe"
p.UseShellExecute = True
p.Arguments = """C:\test.reg"""
Process.Start(p)
Sending the Registry edit command to CMD
Dim process As New Process()
process.StartInfo.FileName = "cmd.exe"
process.StartInfo.Verb = "runas"
process.StartInfo.UseShellExecute = True
process.StartInfo.Arguments = "/K reg add ""HKEY_LOCAL_MACHINE\SOFTWARE\Software\Licenses\Serial Numbers"" /f /v ""Software"" /t REG_SZ /d """ + licenseKey + """"
process.Start()
Running the Windows Batch Script through CMD in a similar way to above
'Code is much the same as above
All of these methods worked perfectly with editing a Key in HKEY_CURRENT_USER. I thought it might be the particular key and the permissions relating to it, but after further testing I found that none of the above code could edit any arbitrary key in HKEY_LOCAL_MACHINE.
I've looked at just about every link on Stack Overflow relating to this and no-one seems to be having the same problem as me. I suspected it might have to do with the privileges of my user account on the office network, so I took the code and tested it on my home PC but to no avail.
At this point I'm really at my wit's end and would greatly appreciate any help!
Thank you in advance for reading :)
This is caused by the Registry Redirector. (Noted: This link seems to be written in the win7 era and kind of outdated). Your program is 32-bit, when running on a 64-bit OS, the call to registry is redirected to the 32-bit logical view of the registry.
In Visual Studio, compile your program to target AnyCPU, also uncheck the "Prefer 32-bit" checkbox. Then the program would run as 64-bit on 64-bit OS, and 32-bit on 32-bit OS.
I am using Visual Studio 2012 and Visual Basic .NET to build the application (with Windows 7)
I currently build the install package and i install to another pc to test program.
When I was creating txt file by my app, i was getting "Access to the path 'C:\' is denied" error
I know that I was using sub account to run my application.
If I run as administrator, it is was working fine. However, the program should be able to run application without using administrator account .
These are what I tried to solve this problem so far.
First, I change the location to write file in "Program file folder" such as "C:\Program file\My App"
However, it didn't work
Second, I was trying to change
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
to
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
at app.config
However, After I replaced to "requireAdministrator" , I am getting compiling error
ClickOnce does not support the request execution level 'requireAdministrator'. WindowsApplication2
Third, I went to Computer->manager->service-> and Enable Application experience.
However, it does not work.
I am not really sure what to do for this problem.
Does anybody know any solution ?
thanks
Dim UserAccount As String = "<user here>" 'Specify the user here
Dim FolderInfo As IO.DirectoryInfo = New IO.DirectoryInfo("path")
Dim FolderAcl As New DirectorySecurity
FolderAcl.AddAccessRule(New FileSystemAccessRule(UserAccount, FileSystemRights.Modify, InheritanceFlags.ContainerInherit Or InheritanceFlags.ObjectInherit, PropagationFlags.None, AccessControlType.Allow))
FolderAcl.SetAccessRuleProtection(False, False)
FolderInfo.SetAccessControl(FolderAcl)
Note you have to add: Imports.System.Security.AccessControl
By the way I got it from here: Give folder full access when created so credit goes to that person. (Jacques Bronkhorst) Hope this solves the issue :)
I want to execute autoit script using vb.net in vs 2010. While executing it keeps prompting. Is it possible to embed a manifest file in a class lib type project in vb.net. As currently I cant see any option to add a manifest. Or plz any other suggestions to disable that prompt to occur while executing a script from code.
There is no way to stop the prompt if you have UAC enabled and the script requires elevation to perform some task.
You can force the script to run elevated by doing something like the following:
Dim proc As New ProcessStartInfo
With proc
.FileName = "C:\Windows\regedit.exe" 'replace with your script name
If Environment.OSVersion.Version.Major >= 6 Then ' Windows Vista or higher
.Verb = "runas"
Else
' No need to prompt to run as admin
End If
Process.Start(proc)
End With
Your only other option is to turn UAC off
Exit code 1625 is "This installation is forbidden by system policy. Contact your system administrator."
What I'm doing is calling it this way:
Process installProcess = Process.Start(msiPath, "/quiet");
I can run the msi fine if I open it manually. This is on windows server 2008...
The intent of this is to automatically update my .net forms program with the latest version. Anybody have a clue what sort of setting is causing this? I mean, the clients are going to be using vista/7/xp, but I still need to know what kind of security settings will ruin my plan.
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.Arguments = "/i " + "\""+Directory.GetCurrentDirectory()+"\\"+msiPath +"\"" +" /q";
startInfo.FileName = "msiexec.exe";
startInfo.Verb = "runas";
Process installProcess = Process.Start(startInfo);
Calling the msi this way did the trick.
Turned out to be some kind of UAC issue I think. The runas verb somehow elevates the permissions the program has. Even though my UAC prompts were disabled on server 2008 I still had to do this to get around it.. strange huh?