Environment: VS2008 .NET 3.5 - VSTO runtime 3.0 - Excel 2007
We have published the VSTO Excel document level customization to network path. All our users are able to copy the .xltm file from the network location to desktop(all the assemblies are still in networkpath) and able the run the customizations when the file is opened. When file is opened, it asks for install and user installs and proceed. It works fine. But, all these users are administrators to their machine. But, there is one special case. One of the user is using server machine to use these customizations and he is not an administrator on that machine. When he tries to open the .xltm file, he is getting error
Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException:
This document contains custom code that cannot be loaded because the
location is not in your trusted locations list: XXXX.XLTM. If you
trust this document you can save and open it from a location on your
computer. For more information, see
http://go.microsoft.com/fwlink/?LinkId=99104. at
Microsoft.VisualStudio.Tools.Office.Runtime.RuntimeUtilities.VerifyDocumentIsTrusted(String
documentFullLocation, String documentName, OfficeVersion
officeVersion) at
Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String
solutionLocation, String manifestName, String documentName, Boolean
showUIDuri
We added the \networkpath and subfolders to Excel trusted locations, enabled all macros. But, still he is getting the error. I also added the file://networkpath to trusted sites in IE. Still no luck. Still he is getting the error.
Related
OK, so we have written a utility (using Graph API) to allow us to authenticate and access files on our internal SharePoint online sites, to replace previous on-premise WebDav access, and we are having issues with the online files after they have been copied.
In simple terms, using Graph API, the process takes a file path from SharePoint Online, authenticates with the site and if the user has access to the file, copies it to a defined location. This works exactly as it should and the relevant files are correctly copied to the new location. For on-premise files, the location remains unchanged. The online files are copied as we can't find a way to integrate Graph API into SSIS, so the files need to have any permissions removed by copying them somewhere else.
We have an existing SSIS process which previously read from a list of on-premise file locations and imports the data from each Excel file into a SQL database. This worked without issue until we updated the list to include the SharePoint Online copied files. The SSIS process runs under the context of a service account, which also has read/write access to has defined location, but when the SSIS task runs, it returns with the following error:
Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft Access Database Engine" Hresult: 0x80004005 Description: "Cannot update. Database or object is read-only.".
I've obviously searched for this error, and the only suggestions are to set IMEX=1 on the connection, which is already done, and to set DelayValidation = True, again this is already done.
The SSIS process should work the same for both the existing on-premise files as it does for the online ones, but for reasons unknown, the on-premise ones work as expected, but the online ones fail. The file isn't already open elsewhere, it's copied and then the SSIS process attempts to open it, but that's where it goes wrong. I can open the copied file without issue in Excel.
Is there something about SharePoint Online that leaves a lock on a file? Is there something we need to do using Graph API to release the copy from any links to SharePoint? Myself and my colleagues have all looked at this and can't figure out why the copied files don't open.
EDIT: Looking at the context of the SSIS error, it seems the ConnectionString is valid, as is the ExcelFilePath (which matches the Data Source in the former):
ConnectionString: Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\\OUR_SERVER_NAME\ShareName_UAT$\Excel_Macro_Enabled_File.xlsm;Extended Properties="Excel 12.0 MACRO;HDR=NO";
ExcelFilePath: \\OUR_SERVER_NAME\ShareName_UAT$\Excel_Macro_Enabled_File.xlsm
Any ideas or advice gratefully received.
Thanks
Martin
Maybe it's related to Excel protection measures when the source file is originated from the internet?
Sometimes it helps if you open, save and close the file before reading it with ssis (https://stackoverflow.com/a/59865686/5605866)
I am attempting to deploy a custom MS Excel add-in across our network environment following this article: https://www.excelguru.ca/content.php?152-Deploying-Add-ins-in-a-Network-Environment.
One users computer is causing trouble for me. I install as directed, specifically when asked, I say "NO" to copying the file to the local user's folder. Initially the add-in appears to have installed and work properly. However, upon restarting Excel, I find that in fact, Excel gives the error message stating the add-in is missing and has a file path to the local users folder. I have tried multiple times to the same outcome.
On other users PC's (win7 and win10 boxes) the file installs fine from the network and remains after a restart of Excel. So far, the issue appears to be isolated to one user's PC. He is on windows 10 and excel 2016.
Has anyone encountered this? To me seems like a bug maybe?
I've seen that happen if the user initially selects to copy it locally, then removes it, and then tries to add the network copy. The only fix is to edit the registry to remove the local reference, and then add the network copy again.
It's important for the end users to not copy the file locally the first time, or you end up in this mess.
Search their registry for the filename of the add-in and delete it.
I have written an VSTO Excel 2010 AddIn and successfully installed it on a machine that is not my development machine. I installed it manually by first creating a folder to hold the AddIn application files. The folder is C:\TestXL2010. I then placed all of the files from my machines project bin\release folder into the TestXL2010 folder on the test machine. Next I created and ran the installation registry script that contains the following lines.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\TestXL2010]
"Description"="TestXL2010"
"FriendlyName"="TestXL2010"
"LoadBehavior"=dword:00000003
"Manifest"="file:///C:/TestXL2010/TestXL2010.vsto"
At this point, everything appears to function as expected. Now the problem. I made some changes to the application, rebuilt the solution and copied the new set of files into the TextXL2010 folder. Excel does not appear to see the new files. It is acting as if it is still running on a cached set of the original files. I have tried uninstalling, renaming, etc. to no avail. Excel just appears to be stuck on the first version of the application. Any suggestions as to what I need to do to either clear the cached version or make Excel see the new version would be greatly appreciated.
well this could be because application is getting loaded from clickonce cache, to avoid append |vstolocal in manifestpath like "Manifest"="file:///C:/TestXL2010/TestXL2010.vsto|vstolocal", . vstolocal ensure that your solution is loaded from the installation folder, rather than the ClickOnce cache.
Check your system Task Manager for a background Excel.exe process running. Kill it or reboot to clear it. If an add-in fails, a copy of Excel may keep running in the background and it prevents new or changed add-ins from taking effect.
We have bought Team Viewer corporate, and need to deploy to our infrastructure, it includes Windows XP SP3, and Windows 7, our domain controller is Windows 2003 SP2, the setting of Team Viewer was exported to .reg file including the passwords and whitelists, I used the .vbs that Team Viewer provided to merge the registry values we exported earlier.
At a testing environment that matches the real environment, the deployment itself runs perfectly using GPO, but the script doesn’t run, if I tried to run the script manually by double clicking the .vbs file, I get “open file security warning” dialogue box, so I disabled it at the attachment manager by adding .vbs to the low risk list and everything worked fine, but the management refused this solution since it will endanger the network by marking all .vbs files as safe, and because it uses “user configuration” rather than using “computer configuration” at GPO, why does this matter? Because users are mobile throughout the regions where we operate, and when a user logs in using their credentials they will trigger the script and the deployment which will affect the network bandwidth.
My question, is there any way to deploy Team Viewer and merge the registry file through .vbs using “computer configuration” at active directory GPO?
Here's an interesting article that suggests using .adm files (instead of .vbs scripts) to propagate a registry change to your users, using Group Policy:
http://blogs.technet.com/b/askds/archive/2007/08/14/deploying-custom-registry-changes-through-group-policy.aspx
I have an add-in in Excel that needs to store some data in the HKEY_LOCAL_MACHINE registry. because of the UAC control in Windows Vista and earlier versions, I added a manifest file. But it is just not working. I even added the manifests in each of the projects of my solution. I have 5 projects in my solution (3 VB projects, 1 c++ and 1 deployment).
I am using VS2005. I added the manifest file to the project (with the requestedExecutionLevel set to "requireAdministrator" and embedded the manifest using mt.exe in a post-build command.
Even with that, I am still getting an access denied to the HKEY_LOCAL_MACHINE. The only thing that is working is when I start Excel as "Run as administrator".
Any clue what the problem might be? Thanks.
Manifests in DLL do not affect the execution level of the application, in this case it's excel.exe.
Here are the options you have:
to run Excel as administrator;
to modify the add-on to write to HKCU rather than HKLM.
If you need to store data available to other users, consider using ProgramData folder (CSIDL_COMMON_APPDATA or FOLDERID_ProgramData). Then your add-on creates a subdirectory inside ProgramData and modifies its permission so that this new directory is writable by anyone (by default, only the user account that created the folder has write permissions, other users can only read).
There are some other options:
You can write a service that your add-on will communicate to write data into HKLM but it's not.
You can create an elevated COM object which will write the data into HKLM.
Although users don't expect Excel to require elevation when run, therefore consider changing your logic so that your add-on does not require elevation at all.