Cannot create ActiveX componet [VB.net]
That's because it requires adminstrator privilege. Change the project's setting from (#2 is required if it is Win32 program)
1.project -> properties -> Application -> View UAC settings:
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
2. project -> properties -> Compile-> Advanced compile options -> Target CPU
X86
========================================
An article descripts the detail:
Banish UAC Issues
User Account Control (UAC) issues usually result from improperly allowing administrator-level access in your applications. Learn how UAC works and make such problems a thing of the past.
By Kathleen Dollard
11/01/2007
Get Code Download
Q. My users are getting a security error when they run my application in Windows Vista. This application ran fine on XP, and I think it has something to do with User Account Control (UAC). All my users have administrator privileges on their own machines. I'm using Visual Basic in Visual Studio 2005 on XP for development. What do you think is wrong and how do I fix it?
A. Your problem probably is a UAC issue. Historically, some programs have been written in a manner that required administrator privileges. After years of cajoling developers to write their applications in a more secure manner and encouraging users to run with lower privileges, Microsoft gave up and fundamentally changed the security model, knowing it would break some applications.
In Vista, users don't run with administrator privileges, even if they log on as administrator. When they log on to an account approved for administrator access, they run as a normal user, and Vista remembers their password so it can elevate the account when users approve doing so explicitly. This is critical to improving security because it limits the damage a rogue application can do without your consent.
Knowing that many programs were not ready for this change, Microsoft created a side channel work-around for the two most common ways applications can fail UAC: writing to the Registry and writing to files within system directories. These scenarios still work under Vista because accessing these locations was once common practice, and it's bad to break legacy applications. This isn't specifically part of your problem, but I'll include an explanation after addressing your problem because it can really trip programmers up, and it's tricky to solve in .NET 2.0. I'll also explain how .NET 3.5 makes your life easier.
The first thing you must do is find out what is causing the UAC problem. Ideally, you should write your applications so they don't need administrator control, but that isn't always possible. When you migrate these types of apps to Vista, you get UAC errors only if you do something that requires administrator control. The problem will also be difficult to find unless you can run Visual Studio in Vista. Under Vista, start Visual Studio without administrator privileges. To ease other debugging issues, my menu shortcut runs Visual Studio 2005 with elevated privileges, but I'm careful not to use my shortcut when testing this issue. Instead, I double-click on the executable in Windows Explorer to run as a normal user. When you're debugging in Visual Studio, you run at whatever privileges the debugger has. You should get the same exception your users get when you run an administrator task. I've included an application in the online code that fails (intentionally) because it accesses the event logs.
Once you find the problem, you have three choices: Remove the functionality from your application, isolate the administrator functionality in a different application, or require that your application run as administrator. One of the first two solutions is always preferable, and you should only require administrator privileges if the nature of your application is to do administrator tasks. Administrator tasks are generally not needed in most business applications, so you should make an effort to remove the functionality if there is any other way to accomplish the task. If your app requires administrator privileges, but the overall purpose of your application isn't to perform administrative tasks, you need to isolate the administrator functionality in an ancillary application.
Once you've refactored the administrative tasks into their own application, you might want to access the new administrative tasks app from the main application. You can do this through a button-click at a logical point in your main application. A key aspect of the Vista security model is that you warn your user when an action requires elevated permissions by displaying the shield icon (see Figure 1). You can display it on a button using the SendMessage API:
Public Class Win32
Friend Declare Auto Function SendMessage _
Lib "user32.dll" ( _
ByVal hWnd As IntPtr, _
ByVal msg As UInt32, _
ByVal sparam As UInt32, _
ByVal lparam As UInt32) _
As UInt32
Friend Const BCM_SETSHIELD As Int32 = &H160C
End Class
I put the declaration in a separate class for encapsulation. Other Win API declarations could also be included in this class. A utility function sets the icon:
Private Shared Sub AddShield( _
ByVal button As Button)
button.FlatStyle = _
Windows.Forms.FlatStyle.System
Dim success As UInt32 = _
Win32.SendMessage( _
button.Handle, _
Win32.BCM_SETSHIELD, 0, 1)
End Sub
When your application runs under XP or another down-level operating system, the shield message is ignored.
In the test app, the AddShield method is on the form, but in a real application it would probably be in a utility library. The AddShield method sets the button's FlatStyle to System. The System style is required for the shield to appear, and it's easier to set the FlatStyle when the shield is used, rather than expecting later programmers to remember this detail. For debugging purposes, this code captures the success return value. It calls the AddShield method from the OnLoad method unless the user is already an administrator:
Protected Overrides Sub OnLoad( _
ByVal e As System.EventArgs)
MyBase.OnLoad(e)
If Not IsAdmin() Then
AddShield(Me.elevateButton)
End If
End Sub
You can determine whether the user is an administrator by checking whether he or she is in the administrator group:
mt -manifest
"[Path]/[ManifestFileName]"
-outputresource:
"[Path]/bin/Debug/[ExecutableFileName]" Note that you enter this snippet as a single line, and the outputresource argument is followed by a colon.
I mentioned at the start that Vista supplies a stopgap measure for the two most common scenarios where programmers historically demanded administrator privileges. Vista supplies virtualization for protected registry entries and files in system directories. This keeps applications from breaking outright, but it can lead to unexpected behavior, particularly when multiple users on a machine expect to share the same registry entries and files. You can fix this by removing your use of these protected locations. The problem lies in testing your application to ensure that you don't depend on virtualization.
You can disable virtualization by supplying a manifest.
Vista assumes that applications without a manifest are not Vista-aware and might need virtualization to help them operate correctly. Vista also assumes that applications with a manifest are Vista-aware and have their UAC issues in order, so they don't need virtualization.
Adding a manifest with the requestedExecutionLevel set to "asInvoker" is a great way to test your application. A benefit of using the manifest approach to testing is that it puts you one step closer to Vista logo certification.
If embedding a Vista manifest seems like a lot of trouble, you'll be happy to learn that Visual Studio 2008 includes tools for both C# and Visual Basic that make it easy to embed manifests and access them for editing.
[I'm always learning from other programmers, and this topic is no different. Special thanks to Daniel Moth and Bill McCarthy for providing information related to this topic. --K.D. ]