I’m well aware of the Microsoft support base article stating that it’s not supported to automate office products UI less. It seems that Windows Server 2008 x64 and Excel 2007 enforce the given statement.
I’m running the following code in a NT Service (Local System account) OnStart method. All it does is Excel automation the way it’s working when you run the same code in a Console Application.
The provided code has two parts. The first part launches Excel, creates a new work book and saves it to the given filename. The second part launches a new instance of Excel and opens the given file. The open operation ends in this exception:
Service cannot be started. System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file 'c:\temp\test.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.
Why was the automated excel able to launch and write files to disk but fails when it’s asked “just “ to open an existing file?
System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
// launch excel and create/save a new work book
Microsoft.Office.Interop.Excel.ApplicationClass excel = new Microsoft.Office.Interop.Excel.ApplicationClass();
excel.UserLibraryPath, excel.Interactive));
//
string filename = "c:\\temp\\test.xls";
if(System.IO.File.Exists(filename)) System.IO.File.Delete(filename);
//
excel.Workbooks.Add(System.Reflection.Missing.Value);
excel.Save(filename);
excel.Quit();
excel = null;
// lauch new instance of excel and open saved file
excel = new Microsoft.Office.Interop.Excel.ApplicationClass();
try
{
Microsoft.Office.Interop.Excel.Workbook book = excel.Workbooks.Open(filename,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
true,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
false,
false,
System.Reflection.Missing.Value,
false,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value);
book.Close(false, System.Reflection.Missing.Value, System.Reflection.Missing.Value);
book = null;
}
finally
{
excel.Quit();
excel = null;
}
//
GC.Collect();
The solution is really simple. The msdn forum thread can be found here
To make a long story short I'm posting the solution here, credit goes to H Ogawa
This solution is ...
・Windows 2008 Server x64
Please make this folder.
C:\Windows\SysWOW64\config\systemprofile\Desktop
・Windows 2008 Server x86
Please make this folder.
C:\Windows\System32\config\systemprofile\Desktop
...instead of dcomcnfg.exe.
This operation took away office automation problems in my system.
A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.
It disappears from Windows2008, Windows2003 had the folder,
and I think it cause this error.
Also like stated in the source, you need to set the correct rights for the Desktop folder.
This worked for me on Windows 2008-64bits and Office 2010 32bits.
Create directory "C:\Windows\SysWOW64\config\systemprofile\Desktop " (for 64 bit Windows) or "C:\Windows\System32\config\systemprofile\Desktop " (for 32 bit Windows)
Assign user "Network Services (Service Réseau)" the following rights for the created folder:
Read & Execute, List folder contents, Read
John.
I've quite often found that calling Quit() isn't enough to release the resources. Try adding: -
System.Runtime.InteropServices.Marshal.ReleaseComObject(excel);
between the Quit() statement and setting it to null.
There are many more errors than the one mentioned that you'll need to work through in order to get Excel working on Windows Server 2007 64-bit. See the steps I worked out after working on this for two full days!
If you are using Apache, you might also need to follow these steps to get MS Word working properly (along with everything outlined in other answers):
Below is a screenshot showing the two dialogs you'll need to bring up:
For Apache:
Services->Apache->Right Click (Properties)->Log On Tab
MS Word:
Launch dcomcnfg.exe->Console Root->Component Services->Computers->My Computer->DCOM Config->Find Microsoft Application->Right Click(Properties)->Identity Tab
**if you can't find the MS Word, make sure you are launching the correct DCOM Config (64 bit vs 32 bit) depending on what version of Office you have installed.
There are two options here, you can set Apache to use Local System Account and check the checkbox to ALLOW desktop interaction. If you do this then you need to set the Identity for MS Word to Interactive User.
Otherwise, you need to set both to the same user (Ideally the user that is logged in) like shown in the picture.
Related
I'm trying to automatically save workbooks using VBA to a Sharepoint folder- which needs to be created first.
Code I have below works ONLY for saving the file. The MkDir function returns a Run-time error 76: Path not found. I'm at a loss what causes this error, because the path before /txt DOES exist and I do have the right permissions to add new folders by hand. I have also tried replacing the current path with \ instead of /, but other than making the code significantly slower this has no effect. No "solutions" online have done the trick for me.
Any ideas?
MkDir "https://placeholder.sharepoint.com/teams/Services_NL/Shared Documents/txt"
DateAndTime = Left(Replace(Replace(Replace(Now, " ", "_"), ":", ""), "/", ""), Len(Replace(Replace(Replace(Now, " ", "_"), ":", ""), "/", "")) - 5)
ActiveWorkbook.SaveAs "https://placeholder.sharepoint.com/teams/Services_NL/Shared Documents/Export/" & ExportSheet & DateAndTime & ".txt", FileFormat:=xlTextWindows
I had tried all different combinations of forward slash and backslash, "https://"...etc. But I finally got the MkDir command to work using the following syntax:
MkDir "\\mysite.sharepoint.com\IS\Shared Documents\My Docs\" & "MyNewFolder"
Note: Replace any %20 (used by Sharepoint to substitute a blank space in the URL) with a blank space. Or better yet, copy the folder address directly from the Windows Explorer navigation bar and then add the backslash to the end of it.
Also, I believe its important to first test the ability of your environment (permissions or otherwise) by opening your Sharepoint directory folders within Windows Explorer and navigating through them as a test. If you can do this, then MKDir command should work because you've proven the file directory is accessible.
The "Open with Explorer" icon is found on the Library tab within Sharepoint (I'm using Office 365). I've found that in some Sharepoint environments I've worked with the Library tab is accessible by default, but in others it is hidden (only the Browse and Page tabs are viewable). In that case, I got the Library (and Files) tab to appear by navigating into a Sharepoint folder, highlighting a bunch of files, and then just right-clicking on the highlighted section without clicking on any of the flyout options. Odd behavior, but it worked.
I am having the same issue, using Office 365 from both Win 7 and Win 10 to Sharepoint 2013. It may relate to a security feature which interferes with file System Object actions to online addresses with VBA, resulting in
error 76 path not found; and error 70 permission denied; and also
error 52 bad file name.
We have several Win 10 Office 206 users with VBA, macros, trusted locations, user permissions, explorer navigation, UI folder creation, etc are all fully functional, and set in MSWord and SP2013: errors 70, 76 and sometimes 52 result when the VBA tries to Save As to the Sharepoint folder they all have unfettered access to.
The same users, running Office 2010, to the same server, using the same VBA, have no problems with file system Object saving, navigation etc.
I have found that mapping and un-mapping the Sharepoint 2013 path/drive/folder, in the session with VBA seems to make it work. I tried that on Fri Feb 22 2019. In the VBA immediately before the navigation and creating folders code, I mapped the Shared Documents library to the next available drive (step through if exist for drive-letters 67 to 89, then do the Save As, then remove the mapping. I'll be testing more tomorrow Mon Feb 24 2019.
my path string is: \\sp.url#ssl\davwwwroot\site\subsite\shared%20documents
and the drive letter as noted is dynamic based on whatever the user has.
The path in my string therefore is using teh WebClient service, and that has been very reliable for me under SP2013. until Office 365/Office 2016 that is.
WebClient and Office 2016/365 in Windows 10: I have encountered exactly the same set of circumstances moving from Win 7 + Office 2010 to Win 10 + Office 2016/365. FileSystemObject activity using WebDAV now does not work with the (former fully functional) WebDAV path \sitename#ssl\davwwwroot\site.
I get error 70, 76 when attempting to traverse the path, or create a file system object on that path. Mapping and unmapping works, but wow - that seems a redundant and clunky procedure when the path is already authenticated, apparently except to WebClient.
Adding AuthForwardServerList as new Multistring DWORD parameter to HKLM CurrentControlSet Service WebClient makes the system function, but I cannot state that it will always allow the FileSystemObject to be created, even if the path is mapped ; see https://support.microsoft.com/en-us/help/943280/prompt-for-credentials-when-you-access-webdav-based-fqdn-sites-in-wind
I think the path problem is a Win 10 system issue.
An additional problem is Access Denied, which I think is due to a security "feature" in Office 2016/365, I think intended to control FileSystemObject activity in online locations.
Finding information on Add-In development for Microsoft Access is like getting all of your teeth pulled! Yes I've found the couple Managed Add-In Articles written... but could find next to nothing for Un-Managed Add-Ins. I did find one great article which is very old in creating basically an unmanaged .mda project... which I've followed and created a add-in. Now I would like an automated way to deploy this add-in.
I've seen it done from VBA with such tools as Rick Fisher's Find and Replace add-in tool... but can not find a way to do this programatically in Access. I have found lot's and lot's of articles on Excel Add-In's and even Excel Add-In Installation. One such method uses VBA like so:
Sub InstallAddIn()
Dim AI As Excel.AddIn
Set AI = Application.AddIns.Add(Filename:="C:\MyAddIn.xla")
AI.Installed = True
End Sub
Unfortunately Access does not use the same method. If anyone could point me in the right direction I would greatly appreciate it. AND if anyone knows of any books or references that goes more in-depth to developing Add-Ins for Microsoft Access that would be greatly appreciated as well as most of the picking seem slim.
This is just a bad idea. To be honest, I'm not sure where it's even located in the current version of Windows/Office. I have found Word and Excel at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office, but I have Access installed and I don't see an Access folder there. At one point, Access add-ins were accessible through this registry key:
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Microsoft\Office\11.0\Access\Menu Add-Ins
This worked for Office 2003 on Win Vista. But it changes every time Microsoft updates Office/Windows, so trying to do it programmatically would be moot because you would have to update and roll out a database change every time you updated Office or Windows.
If you target the main registry hive there is logic that will put the key in the correct location for you. For example, you never hard code Wow6432Node because that location is automatically managed by 64-bit windows when a 32-bit application tries to use the registry. Likewise, in modern C2R versions of office the registry location is in a really strange place. You don't have to worry about it. If you target the main key from Access, the key will end up in the correct location magically.
If you want to install per user I recommend using the following locations.
Put the file here:
Private Function GetAddinFileName() As String
GetAddinFileName = Environ$("AppData") & "\Microsoft\AddIns\" & CodeProject.Name
End Function
Use this registry location:
Private Function GetAddinRegPath() As String
GetAddinRegPath = "HKCU\SOFTWARE\Microsoft\Office\" & _
Application.Version & "\Access\Menu Add-Ins\"
End Function
I'm building a program that makes excel based reports using xlsx files using the Microsoft.Office.Interop.Excel library and Visual Studio 2010.
I have a xlsx file with 2 charts, and some styles. Using...
Dim LibroExcel As Excel.Workbook
Dim HojaExcel() As Excel.Worksheet
LibroExcel.Worksheets(1).copy(After:=LibroExcel.Worksheets(i))
HojaExcel(i) = LibroExcel.Worksheets.Item(i + 1)
... I copy that sheet to another sheet until the for instruction I use ends.
The problem: In a system with Windows8 when I use this function, the charts are not copied from one sheet to the next one. But if I do the same on a Windows 7 system, it works. Both systems are using the same version of Excel.
I have been searching on the internet, and following the steps on the next post i have resolved my problem:
https://stackoverflow.com/a/13174856/4587472
Also i applied the next steps because the first time i didn't found Microsoft Excel Application:
On 64 bit system with 32 bit Office try this:
Start
Run
mmc -32
File
Add Remove Snap-in
Component Services
Add
OK
Console Root
Component Services
Computers
My Computer
DCOM Config
Microsoft Excel Application
Anyway, can someone explain what this steps really do? (This steps and the post steps)
I'd like to be able to get and set the different information for a user in Active Directory on Windows Server 2003 under Environment and Session tabs through a VB.Net application. I am familiar with System.DirectoryService but I can not find the correct attributes for these particular tabs. For example, I'd like to check "Connect Printer at logon" or set "Idle session limit".
I've found the "ms-TS-Connect-Printer-Drives Attribute" and other attributes like it but they are only implemented on Server 2008. There must be another way for older version.
I've found the answer after many research.
There is some information you just can't get and set through DirectoryServices under Windows Server 2003, especially under tabs like Session, Environment, Terminal Service, etc
There is a DLL that can do it for you: TSUSEREX.dll found in Windows/System32.
Adding a reference to that library in your visual studio project, here is an example on how to use it to get what you need:
Have a directory entry(dirEntry) pointing on the user you wish to work on.
Dim oUser As ADsTSUserEx = CType(dirEntryUsr.NativeObject, ADsTSUserEx)
oUser.MaxIdleTime = 10
oUser.ConnectClientPrintersAtLogon = 1
This will set the max idle connection time to 10 minutes and have the printer connected automatically.
I have run into an odd problem while attempting to register a vendor-supplied ActiveX control on two different computers. On one computer, I can register the part using regsvr32, and then use it in an Access 2007 form with no problems. On the other computer, after I register the same DLL, it is simply not recognized as a valid ActiveX part by Access 2007, or any other Office 2007 program.
The ActiveX part is contained in a single DLL. I am not missing an additional file on one of the computers.
I cross-checked the exact version of the DLL on both computers using md5sum. Both DLL files are exactly identical.
I cross-checked all of the registry entries generated when the part is registered, using the Nirsoft ActiveX Helper utility. The entries are identical.
I checked Access to make sure that the part had a reference entry which pointed to the DLL.
I checked that the location of the DLL was specified as a Trusted Location in Access.
Unfortunately, I am not enough of a COM expert to know whether or not I am overlooking something odvious. Any additional ideas would be appreciated.
OK, total shot in the dark, but we have some computers in our organization the the IT has locked down pretty tight. When we run setup's they run OK and register our ActiveX components, but the first time we run the program it has to be as an administrator. After that the normal user is able to run the program.
You could try a simple VBS script to verify that the control can be created.
Using Notepad (or similar) save the following as test.vbs, and then double click it to run it.
set oTest = CreateObject("<YOUR PROGID HERE>")
MsgBox ("All Done Successfully")
You should get an reasonably descriptive error or "All Done Successfully".
This would at least point to whether its a system wide or Office specific problem.
And if you get an error it may well point to the actual problem.
OTH, if you don't get an error then you probably have an Office installation issue - which could be resolved by a re-install.