The strange problem I am having now is the Excel 2010 Add-in won't let me use the newer version. For some reason, it is still pointing to the old version and displaying the old UI.So my first impression about this is perhaps Excel caches stuff in the background or something.
This problem seems to be disappeared if I set the Add-in LoadBehavior value to 16 or 3 instead of 9 (the default value is set to 9). But I am not sure if it's a fix or probably I just somehow get lucky. Anyway, I hope someone can help explain a bit further about this problem. Thanks.
Have you appended "|vsto" to manifest path (check registry software/microsoft/office/exce/addins/[your addin name]/manifest. if this is not done vsto will always pick dll from clickone cache
Related
I've written a Excel-Dna based Addin in C#.
Used the following technique to register it at users computer (from WixInstaller and ManageOpenKey):
Locate the active Excel version key in registry (16.0 for this example):
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Options
Write the path of the XLL in the first available string value named
"OPEN". As seen in this screenshot, my Addin is written at "OPEN1" key.
Everything works as expected in the installation, but the problem starts if one of the addins is uninstalled using WixInstaller.
For example, if value "OPEN" is removed, addins at "OPEN1" and "OPEN2" will stop functioning. Excel explicitly looks for "OPEN", "OPEN1", "OPENXXX" sequence and if one of the values is missing - it stops enumerating.
I checked the source code of ManageOpenKey - it "blindly" removes the addin key even if this operation breaks the sequence.
Only solution I am thinking, is to write a function that re-orders all the keys. This does not look so difficult, but my question is:
Have anyone found a solution for this?
Yes you would have to rewrite the OPEN keys so that they are in contiguous ascending sequence.
Also worth removing the key from the ADDINS hive in case a user has used the XL Addin manager to move it from the active to the inactive list of addins.
Charles Williams answer is correct. When uninstalling an Excel add-in, you should rewrite & reorder the values in the registry that comes after the add-in being uninstalled (if any).
I've added an issue to the Excel-DNA WiXInstaller Template repo, for us to fix it.
Uninstalling add-in can break other add-ins
I had an issue with Excel workbook opening. After some research I've found a way (https://support.microsoft.com/en-us/kb/320369) to solve this issue by changing the CultureInfo of the current execution thread.
Does anyone could bring me more information about this issue ? I mean, why this issue is happening? Is there a way to know where the problem is coming from exactly ? (Is this from a specific column or row ? Does it related with some properties within the .xlsx file ?...)
Hope I've been clear.
Thanks.
P.S: Sorry for my english
The first two solutions set your thread's culture information to match what Excel is expecting. The last solution does the reverse, and creates the 'missing' localization file.
The CurrentCulture property tells Excel how to localize the GUI. If you are running a version of Excel that doesn't perfectly 'mesh' with your version of Windows, the localizer cannot figure out what localization files should be used. I suspect that the Excel startup code has some logic that figures this out, but it doesn't get executed when you call Excel via automation, so you essentially have to do it manually (ie, any one of the steps described in the MS article).
I am working on an Asp.net web application. Since yesterday I am unable to check in my code. But I am able to get latest code, compare files , View history and create work items.
While check in- Neither the error message is displayed nor The file that needs to be checked in is locked.
Suspect:-
The application is written for VS 2010. But,Once I opened it on vs 2012. Later I made necessary changes to the solution file so that It re-opens on VS 2010 again. Can this be the reason why check in is not working? Please let me now if you have any suggestions. Thanks.
"Lock "Check-in". This is also known as the "antisocial":-). A check-in lock prevents anyone else from committing their changes to that file until you have released the lock. This means that they will be responsible for performing any conflict resolution activities that result. You can place a check-in lock on a file even if somebody has a file checked out with a lock type of "none" i.e. I know you are working on this file but you are not allowed to check in your changes until I have made this important quick fix."
Probably this is the case, someone check out the file after your check out. Check who check out the file and contact with him, this is the best advice which I can give you.
We recently upgraded from Excel 2007 to Excel 2010, and we have found that existing code started failing.
Exception Message:
Office has detected a problem with this file. To help protect your
computer this file cannot be opened.
We have traced this to the line where we open the file
excelApp.Workbooks.Open
Even when opening the file manually, the Protected View Messagebox comes up.
How can we work arround this using C#.
Have a look at using Application.FileValidation Property (Excel) before your Open statement.
Returns or sets how Excel will validate files before opening them.
Read/write
Files that do not pass validation will be opened in a Protected View
window. If you set the FileValidation property, that setting will
remain in effect for the entire session the application is open.
You can set it to one of the enum values in MsoFileValidationMode Enumeration
msoFileValidationDefault
msoFileValidationSkip
if you set it to msoFileValidationSkip before the Open statement, it should bypass the check.
Something like
excelApp.FileValidation = MsoFileValidationMode.msoFileValidationSkip;
before the open statement.
Late to the game here, but this is a common annoyance: you need to define a 'Trusted Location'.
You're not the only developers encountering this problem when your code tries to open a spreadsheet file, and "Office has detected a problem with this file. To help protect your computer this file cannot be opened." is an extremely unhelpful error message.
Look up the Trusted Location code published by Daniel Pineault on DevHut.net in 2010:
DevHut code example: Trusted Location using VBScript
I'll get downvoted to hellandgone for posting VBA in a C# forum, so I'd better not post my implementation of Daniel's code (yes, I'm a VBA developer, bashing out VBA macros all day, not a real coder working with pointy things and curly braces). If you really want to see the VBA, it's in a reply to another post:
https://stackoverflow.com/questions/2962728/office-trusted-locations/28115700#28115700
I believe the proper salutation is 'Share and Enjoy'.
Do, please, put an acknowledgement of the original author, Daniel Pineault, if you reuse the code: it's been widely published without attribution on 'Expert' sites, and that's rather rude.
We had the same issue. Our SSIS package at SQL server uses Excel.Interop to parse files. One day we installed Office 2010 x64 on new server and for some files started getting error:
Office has detected a problem with this file. To help protect your computer this file cannot be opened.
At the same time, other servers work good. We found distinguish in versions of Excel: 14.04763.1000 doesn't work, but 14.0.7015.1000 works for us. The last version number belong to Office 2010 SP2. Eventually we downloaded SP2 and installed it,as result, the error has gone.
COM Excel AddIn, C#, VS2008
The error happens occasionally when I install/uninstall my AddIn.
sometimes I see Error 1001 the specified file can not be found
Anyone know what causes these and how to fix? thanks
I use windows installer
http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=VS.90%29.aspx says if use [TARGETDIR], it should be like "[TARGETDIR]\" or "[TARGETDIR] ". I simply use /filepath = "[TARGETDIR]myinstallfile" in CustomActionData
What I do not understand is it works almost all time and fails occasionally
Also even if I change this to including space or backslash, I can't tell if that fixes issue since the issue does not happen every time. Anyone has experience? thanks
I found this and it fixes the issue though I am not sure I ever use DDE in my program
http://sympmarc.com/2010/02/04/microsoft-excel-error-there-was-a-problem-sending-the-command-to-the-program/
Then I found this http://www.opendylan.org/documentation/opendylan/interop2/inte_278.htm
It talks about COM Server
so I went to cmd, type in "Excel.exe /RegServer", then the error disappears.
I am not really not sure if this solution works for all cases.
In fact, I am concerned that I miss sth in installer.
Here is a Microsoft Support page related to an issue which looks quite similar to yours. So for me it looks like a bug in Excel rather than in your installer.
The article is quite large, but it boils down to making sure that:
your Excel app is not running with elevated rights
advanced setting "Ignore other applications that use Dynamic Data Exchange (DDE)" is unchecked
Other than that you might try to repair Excel installation or follow the advice given in this thread of ASP.NET forums to fix the registry for Excel installation.
I hope it helps someone facing similar issues.
If you get this type of error when uninstalling a VS setup project MSI, then the most likely reason is that TARGETDIR is not preserved between the install and the uninstall, therefore it has no value, and attempts to use it in an uninstall custom action will result in failure to find the file. The easiest solution (apart from always installing to known locations such as common files etc) is to save TARGETDIR to the registry and retrieve it later. In the VS IDE you can create a registry item with the value [TARGETDIR] to have it resolved at install time.