I'm trying to run some VBSCRIPT from within my application. This works fine when I run my program from within VB. But once I add "UIAccess=true" to my manifest and digitally sign my exe with my certificate, I am unable to run the code any more. It gives errors when I try to interface with any program saying "429: ActiveX component can't create object: 'myApp.Application'". Anyone have any idea why it would run fine in the IDE but not with an application with uses UIAccess? Here is the code:
Dim scriptRunner As New MSScriptControl.ScriptControlClass
scriptRunner.Language = "VBScript"
scriptRunner.AllowUI = True
scriptRunner.Timeout = 3000
scriptRunner.AddCode(scriptStr)
scriptRunner = Nothing
In googling around, I found this website.
it says
Applications with the uiAccess flag set to true must be Authenticode signed to start properly. In addition, the application must reside in a protected location in the file system. \Program Files\ and \windows\system32\ are currently the two allowable protected locations.
maybe it works in your IDE because your IDE is within \program Files\, but outside of your IDE you are running the signed application NOT within \program files or \windows\system32
Related
-I have the Connection Strings defined for System.Data.SQLite.SQLiteConnection
-I never configured the RsaProtectedConfigurationProvider so I guess this is the default provider and the code
'Declaration
<PermissionSetAttribute(SecurityAction.Demand, Name := "FullTrust")> _
Public NotInheritable Class RsaProtectedConfigurationProvider _
Inherits ProtectedConfigurationProvider
is not needed
-Instead of using the classic code of
ToggleConfigEncryption
https://msdn.microsoft.com/es-es/library/ms254494(v=vs.110).aspx
I'm using this code when I load the form to encrypt the ConnectionString section:
Dim appconfig As Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
Dim constringsec As ConnectionStringsSection = appconfig.ConnectionStrings
constringsec.SectionInformation.ProtectSection("DataProtectionConfigurationProvider")
Taken from https://juan-cuenca.blogspot.com.uy/2015/01/encriptar-archivos-de-configuracion.html
When I run my app from Visual Studio the program works and I can find on my Debug folder the file
myApp.exe.xml and also the file myApp.vshost.exe.xml are both with
<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sB....
</CipherData>
</EncryptedData>
So I think the encryption is working fine at Debugging time.
The problem:
-When I publish my app on my web server and then install the app like any Windows app the program still works, but on my C:\Users\MyUserName\AppData\Local\Apps\2.0\
the file myApp.exe.xml is still with plain text on the ConnectionString section.
(And the other file myApp.vshost.exe.xml is not there)
Do I need to do something more on the code or Publish configuration?? (Maybe one "after install" code?)
Or is something about Windows permissions?
Update info
Well now It's working but with a extrange behavior. After the installation and execution of the program on another computer I have two folders on AppData\Local\Apps.... one of this folder with the APP.Config encrypted and the other one with no encryption at all. I proved deleting this second file and the application still run fine. But why this file exist with plain text after running the program?
on my Windows-Terminal user, I'm trying to have two application point to the same Windows directory, one written in VBA one in VB6.
When calling the GetWindowsDirectory() API from VB6 it returns the correct path
C:\documents and settings\%user%\Windows
When calling it from VBA macro, it returns
C:\Windows
Notice that same result goes for GetSystemWindowsDirectory()
Thiking may be the VBA code wasn't aware its a Terminal station, I called the GetSystemMetrics(SM_REMOTESESSION) API which returned 1, meaning it is aware that it is a terminal.
The exact same code was used in both VB6 and VBA
Windows 2003R2 , Office version is 2010 64bit (which as i'm typing this, makes me wonder if it's related, knowing vb6 is 32bit ...)
Any ideas ?
EDIT: as explained by IInspectable below, the difference between vba and vb6 is because vb6 is not Terminal-Service-Aware like Office is.
The behavior you are observing is documented. See the Remarks section for GetWindowsDirectory:
Terminal Services: If the application is running in a Terminal Services environment, each user has a private Windows directory. There is also a shared Windows directory for the system. If the application is Terminal-Services-aware (has the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set in the image header), this function returns the path of the system Windows directory, just as the GetSystemWindowsDirectory function does. Otherwise, it retrieves the path of the private Windows directory for the user.
The DUMPBIN tool with the /HEADERS option can be used to verify, whether the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag is set for a binary.
dumpbin /HEADERS WINWORD.EXE
produces the following output (Microsoft Office 2013 32-bit):
OPTIONAL HEADER VALUES
10B magic # (PE32)
...
2 subsystem (Windows GUI)
8140 DLL characteristics
Dynamic base
NX compatible
Terminal Server Aware
...
In other words: Microsoft Office is Terminal-Services-aware, and calling GetWindowsDirectory from a VBA script hosted inside Microsoft Office will return the shared Windows directory for the system.
If you checked your VB6 application with DUMPBIN, you'll see that it isn't Terminal-Services-aware, and calling GetWindowsDirectory will return the private Windows directory for the user.
Additional resources:
/TSAWARE (Create Terminal Server Aware Application)
This is a problem I have never seen before. Whenever I run a certain command in my application, I am getting the error:
Could not load file or assembly 'CADB.Data'. The system could not find the file specified.
When I run the command in the debugger, I do not get this error. The system completes the process successfully. It is only when I am running the built .exe. The .exe is in my debug folder with all of the necessary DLLs (Copy Local = True) including the problem DLL (CADB.Data).
When the system runs this command, it is under impersonation. I put the Debug folder (containing .exe and DLLs) into a folder the impersonated user has full access to. I checked access in the Security tab of file properties, and the user has full access to the folder AND CADB.Data.dll. Still, I get the error message above. When I run the program through any other folder that the impersonated user does not have access to, I get a slightly different error: Could not load file or assembly 'CADB.Data'. Access is denied.
Running the application through the debugger on another workstation throws the error as well. The error occurs at the declaration of the method GetClaimGuidList which is a member of CADB.Data (below).
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using CADB.Data;
namespace CADB.BusinessServices
{
public class ClaimHelper
{
static public List<Entities.Claim> GetClaimGuidList(int caseId, bool includeNotices)
{
DataTable dt = ClaimCmd.GetClaimGuids(caseId, includeNotices);
return Utilities.MapDataTableToList<Entities.Claim>(dt);
}
}
}
Other things tried:
Setting DLL as read/write. It was read-only because the file was originally being edited by VSO and thus had a read-only mark.
Running process monitor to look for an access denied message. I don't find such a message anywhere in the monitor.
Removing the DLL and adding it again from the project (my solution has multiple projects).
Cleaning the entire solution, re-building and re-running the EXE
Deleting the bin folder of every project in the solution, re-building and re-trying
Can anyone help? Any ideas would be greatly appreciated. Thanks.
For some reason, the impersonated user did not have access to the application files created in the bin folder. I went to the Security properties of the folder and added that user to the folder with full access rights. This allowed us to bypass the error. Why the user was not able to access the CADB.Data DLL is still a mystery. In any case, the issue was not present in the published ClickOnce application.
I have a strange problem using vb.net (vs2010) and SQLite database: I made an install package with Setup and Deployment project, everything seems to be working fine. My SQLite databse installs under CommonApplicationData folder and the software under ProgramFiles\ProductName. In the setup project I set a custom action, the user have a choice to run software after install:
/StartApp="[CHECK]"
Private Sub MyInstaller_Committed(ByVal sender As Object, ByVal e As InstallEventArgs)
Dim productName As String = Context.Parameters("ProductName")
StartAfterInstall = Me.Context.Parameters.Item("StartApp")
If StartAfterInstall = "1" Then
Directory.SetCurrentDirectory(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location))
Shell(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\FB.exe")
End If
End Sub
In ApplicationEvents.vb I set at StartUp:
AppDomain.CurrentDomain.SetData("DataDirectory", Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData))
And here comes the strange behaviour: if the user starts application after install, the program connects to another(?) database, not to installed under CommonApplicationData. If the user inserts data, seems everything working fine.
After closing the application and starting new from the desktop/programfiles/users program menu connects the program to the database installed under CommonApplicationData, but he can't see the changes he made launching application after installation. So starting program from desktop/programfiles/users program menu => everything fine, but the first (automatic) start after install is a problem. I can't find out what happens, any ideas?
Has your Installation Administrator-Privileges?
If yes, the following probably happens:
you are writing to ProgramFiles. Windows redirects this to the administrator %appdata%\roaming folder because writing to ProgramFiles is considered bad.
It goes to the administrator account because the installation had administrator-privileges.
When you start your program from the user account, the user-specific %appdata% Folder is used, which is empty.
Do solve that problem:
do not launch your program from the installer.
Create a directory for your program in %appdata% and usw it.
I have create Office Excel application in my machine(XP). and i have placed the application in windows server 2008 giving the following error.
Microsoft Office Excel cannot access the file '\server\Input.xls'. There are several possible reasons:
The file name or path does not exist.
The file is being used by another program.
The workbook you are trying to save has the same name as a currently open workbook.
both client and server systems installed office 2007 and added reference microsoftexcellibrary 12.0
created assembly for the application and calling the code from the form.
I was getting the exact same error, although in my case I was trying to run (from Tidal Enterprise Scheduler) a .NET app that used microsoft.interop.excel.
The answer is already in stackoverflow:
[Microsoft Office Excel cannot access the file 'c:\inetpub\wwwroot\Timesheet\App_Data\Template.xlsx'.
I'll re-list the steps from that link:
Create directory “C:\Windows\SysWOW64\config\systemprofile\Desktop” (for 64 bit Windows) or “C:\Windows\System32\config\systemprofile\Desktop” (for 32 bit Windows)
Set full control permissions on Desktop directory above (for example in Win7 & IIS 7 & DefaultAppPool set permissions for user “IIS AppPool\DefaultAppPool”)
Of course, if you're running a scheduled task rather than WebApp, you'll need to make sure the service account you're using has permissions on that folder.
I had the same error when trying to save to:
C:\test.xlsx
When attempting to save to the root directory, it seemed to cause problems. Changing my path to:
C:\MyExcelTests\test.xlsx
Worked fine
I would make sure no Excel processes are running on the machine before you run this application, that should cover the last point.
The first point looks the most likely issue, the path looks like a partial path or an incorrect UNC path. Try putting the full path to the spreadsheet 'C:\server\input.xls' and see if that works.
To stop the middle point, in the workbook.open command you can specify to open as read-only, this will make sure the application can red the file even if it is locked open by another user.