Before I change to ExcelDNA,
My addin is COM AddIn, developed in C#, VS 2008 for Excel 2003+
my installer is created via Setup project in VS 2008
during install, install.xls is called in Custom Action, which calls an xla to register my UDF
Now, I switch to ExcelDNA,
My addin is changed to
public class Connect : ExcelRibbon, IExcelAddIn
I still use Setup project in VS, keep the same upgradeCode,
during install, install.xls is called in custom action, which calls an xll to register my UDF
This works fine for a new install i.e. there is no older version
However, if there is an older version of myAddin (COM Addin)
if I install new version of my Addin (excelDna version) on top of it,
I expect the new version will overwrite the older verison.
However, an error comes up saying "A problem occurred while an addin was intialized (InitializedFailed)..."
Maybe many people here have similar experience before.
How did you solve the issue? thanks a lot !!
This is related to signed projects.
I used to have two projects(dll) signed and referenced by third dll. Later I remove signing.
and reference unsigned dlls in the third dll.
When I upgrade from previous version, for some reason the two dll are not updated.
So the third one looks for unsigned version of dlls while only find signed version in installation folder. So I got the error of initializedfailed.
I signed both dll again and reference them in my third dll, then upgrade works fine.
more info http://blogs.msdn.com/b/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx
However one issue is, why those two dlls are updated during new install and are NOT during upgrade install?
Is this a bug in windows installer or something I miss? thanks
Related
I have a perfectly working windows forms C# .NET 4 application that uses a SQLite3 database file to store data and display forms.
When I deploy my app on any machine other then the dev machine, I get an exception thrown and it's message is "Could not load assembly System.Data.SQLite.dll or one of its dependencies. The specified module could not be found."
The System.Data.SQLite.dll reference in the project is set to Copy Local = True. Also, I tried manually loading the assembly with Assembly.LoadFile. The dll is placed in the output directory. I also tried setting the platform target to Any CPU as well as x86, no difference. All machines I am working with are 32-bit. What is the issue here? Why is my application trying to load the assembly and can't find it?
Thanks!
I had the same problem after publishing my program to a separate computer. Installing Microsoft Visual C++ 2010 Redistributable Package (x86) on the separate computer fixed the problem.
Note: the separate computer already had Microsoft Visual C++ 2010 Redistributable Package (x64) installed, the x86 version was needed.
'System.Data.SQLite.dll" requires "msvcr100.dll" which is one of it's Dependencies. This will be available only if you installed latest "Microsoft Visual C++ Redistributable" or any other product which internally provides this.
For example, VS2010 will install C++ Redistributable by default. Thats the reason your application doesnot works in some machine but works in others.
You could try pasting the "msvcr100.dll" in your application bin folder and distribute if you dont want to install VC++ 2010 Redist in all the PC's.
Some of the System.Data.Sqlite.dll modules depend on the "Microsoft Visual C++ 2012 Redistributable Package" .
You can find required dependencies on the official download page : http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
The answers already given didn't solve my problem. I tried to deploy to a VMware server. The solution that did help where given here: http://sqlite.1065341.n5.nabble.com/System-Data-SQLite-Deployment-Mystery-td71752.html Two methods are described there.
When i install this sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe, my app is able to find the right dll.
The second method is to add the dll to de app.exe.config in the debug or release dir. If you edit this file directly, there is a change VC will overwrite the file.
My main problem was that i installed the sqlite package manually. I didn't use NuGet, because i'm behind a proxy. If you do use Nuget, the information in the app.exe.config will be provided automatically.
Using NuGet behind a proxy is described here: NuGet Behind Proxy
I have built an Excel 2010 add-in for a customer, using C# and Visual Studio 2010. There's no UI requirement, just UDFs that are callable from the worksheet and from VBA. The same DLL contains an Automation add-in (for the worksheet functions) and a VSTO COM add-in (to provide VBA access to the add-in functions). It has 32-bit and 64-bit builds, and I also built a WiX installer (MSI) for it, also in 32-bit and 64-bit versions.
The sources for this were many and varied, and mostly on StackOverflow (see this for examples) but it has been working fine up to the last release I sent out, about 27-Sep-2014. Since then the only change I have made was to switch from using a pfx-based code signing file to a .snk-based strong name key (for reasons I won't go into because they are peripheral to the issue and anyway I have reverted back to using PFX code signing now). The add-in uses other class library DLLs that are part of the VS2010 solution and are shipped in the installer. The WiX project has not changed in any way.
Recently I built and sent out another release because of minor changes to one of the included DLLs. The customer (using Excel 2010 32-bit) reported that after installing this, Excel can no longer see the UDF names in the Insert Function Wizard, and if they are typed into a cell they just evaluate to #NAME?. If they revert to the previous installer I sent them, that still works.
I tried the new 64-bit installer on my own development machine (Excel 2010 64-bit) and see the same effect. However if I then rebuild the solution in VS2010 on this same machine, Excel can see the names again. (Whether Excel is run from within or outside Visual Studio). Uninstall/reinstall via the installer (or repair) - names gone again. I have tried doing images of the Registry before and after the VS2010 rebuild, but all that seems to change is the location of files from the installed directory to the build directory. The DLL files themselves (and all the GUIDs, TLB etc) are all exactly the same. The UDFs can still be called from VBA via the COM add-in.
I can't post the code as there is too much, so my next step is to build a minimal add-in and installer using the same principles but with only one UDF and no extra DLLs, to see if this issue is reproducible. If it also has the problem I'll post it here. In the meantime can anyone provide a clue as to what could be causing this? What mechanism does Excel use to gain access to the function names in a loaded automation add-in?
I have an office add-in (vsto) that has been working fine for ages.
It launches perfectly, runs nicely no problem, but this is only when debugging from visual studio.
If I now take the files from my bin\debug and move it to another folder, then I register the released version
c:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe "C:\Program Files (x86)\MyPlugin\MyVSTO.dll"
it registers correctly, but will not load in office.
I have tried retricking the registry setting "LoadBehavior" setting it back to 3, but no luck.
office keeps complaining about my add in with the error
"Not loaded. A runtime error occured during loading of a com add in"
So it seems like it is dying when trying to launch. I though there was a missing dll or something, but no such luck, every library i need is in the folder.
This is the exact same machine so shouldnt be a dot net issue
fyi
This is done in C# 4.0 using netOffice
You can not install an Excel add-in using REGASM because it does not setup all required information; you need to deploy your add-in as per MSDN office deployment guidelines, you have two choices:
Click once
Windows installer
Note: VS actually installs the Add-in for you by setting the right information In Excel and the registry, so that you do not need to deploy the add-in manually for every new build.
I haven't worked much with COM, so please forgive my ignorance.
Background: I am working on a project in VS 2010. There is a C# COM DLL integrated into the C# solution, and a Setup/Deployment project as well - the Setup project is set to register the COM .tlb file upon installation.
The problem: A previous version of the C# application, along with it's COM DLL, was present on a PC when someone decided to install the newest version of the C# application, and therefore the newest COM DLL. When this happened, it broke the COM functionality for both versions of the C# application..or that is what I am assuming has happened.
Is this typical COM/DLL-Hell behavior? When both C# applications are uninstalled, and then only ONE is re-installed, everything is back to normal - both apparently can't be installed at the same time.
I have tried changed the GUID for the COM DLL project, changing the AssemblyVersion and AssemblyFileVersion for the COM DLL project - all with mixed results. When I change those items, the new install of the application works (great), but now the old C# application doesn't have working functionality.
Note: there are no errors or exceptions thrown when the COM functionality is failing - the COM calls just seem to do nothing. So it is "silently" failing.
I have been researching this and trying various modifications to no real success...maybe I'm thinking about this the wrong way. Is there anyone else with more experience on this that could give me some insight?
You could use a merge module to install the com object and its successive versions. This would allow you to have multiple versions on the same machine. From Microsoft:
A merge module is like a snapshot of a particular version of a component. A new merge module should be created for each successive version of a component in order to avoid version conflicts.
Check out this link: Installer vs. Merge Module Recommendations
The application I'm talking about consists of vb6 (80%) and c#, .Net Framework 4.0 (20%).
All new components are created with c#. With Microsoft Interop Forms Toolkit 2.1 we create the COM UserControls that we later embed in vb6. For Forms we use normal classes to create and open in vb6 (COM Visible project).
To create the setup we use wise.
Locally everything works fine - The problems only occur when we install the application on a non-developer machine with the wise created setup.
We added a class to open a c# Form to an existing interop toolkit project. It works fine on the developer machine and also when we make a new installation on a pc(non-dev-machine). The new class is just used to open the form.
But when we update our application to a newer version, that class is not working anymore. We have to uninstall the old version and install the new version to make it work again.
Anyone had a similar problems before?
I'm grateful for any advice
This seems like it is an issue with Windows Installer and the sequencing during the upgrade. Does your application allow side by side installs (e.g. Version 1 and Version 2 can be installed at the same time) or does your installer upgrade earlier versions to the latest version? You might try logging the installation and reviewing the log file to see exactly what is happening during the install / upgrade process.
You can log an msi installation by invoking Msiexec from a command line.
This may provide greater insight and help focus your efforts to debugging the problem.
Edit
From what you've described it seems that on fresh installation the install works as expected. When you upgrade earlier versions it would seem that the COM Interop components are not registered properly. This could be an indication that the sequence of events is a little off with regards to when the components are copied to the machine and registered vs. when the existing product is removed. While not exactly identical, see this SO Question and answer for more details. Also, have a look at the RemoveExistingProducts action in Windows Installer for more information.
I would log an installation that you know works without issue (e.g. on a "clean" machine) and then log an installation that you know will fail (e.g. an upgrade) and then compare the two log files using a tool to see if the output is identical. If not, that gives you a clue as to where to look. If they are identical it might be time to engage with the vendor and see if they can assist with determining what's causing the issue.