I am a newbie to using Excel DNA so please pardon if the question is off. I have an ExcelDNA project that I am trying to find the steps on how to publish and deploy on the user's machine. The Application is written in c# using vs2017 and is a class library that I installed the ExcelDna.Integration and Microsoft.Office.Interop.Excel DLLs. The application is small at this point it contains a class called RibbonControl which inherits from ExcelRibbon. In the RibbonControl class, there is an XML tag that declares buttons and onaction methods. This creates buttons in the Ribbon. The functions of the button just write data to the excel sheet using the Microsoft.Office.Interop.Excel DLL. I am not using an a vsto add in or anything just the Excel interop lib and Excel DNA. When building in Release mode the directory looks like this
My question is can I publish this application as is and if so how would I go about doing that. If not what do I need to to get this application published and deployed. Thanks
The intention is that you now have two single-file packed add-ins:
Ribbon-AddIn-packed.xll
Ribbon-AddIn64-packed.xll
These are the add-ins for the 32-bit and 64-bit versions of Excel respectively, and if everything is set up correctly, you need only redistribute these.
But you should first check that the EPPlus.dll was correctly packed and works, so I suggest you copy the appropriate packed add-in into a separate directory on your machine, and check that it works fine from there. If not, copy in the EPPlus.dll next to the .xll, and check again.
The EPPlus.dll dependency would not be packed if you didn't add the required <Reference Path=... Pack='true' /> line into your .dna file.
Once you have the packed add-in working right on your machine, those two files are all you need to distribute (or just one file, if you know the bitness of the Excel installation of the user).
To load into Excel - simplest is to copy the .xll to a convenient directory, then File -> Open from within Excel. Your ribbon should load and everything should work.
Then to install as an add-in that loads automatically, go to the add-ins dialog (either just press "Alt+t i", or navigate with File -> Options -> Add-Ins ... Manage: Excel add-ins) then browse to the .xll and select it.
Related
the question's background is:
I have a solution with excel add-in and excel template projects. the simple function is there is a Ribbon button in add-in that will open the template(.xltx) file in template project to do some business.
I have add the template reference in add-in, so the dependency section existed in the add-in's manifest file.
problem is : I published the add-in project by clickonce and install it. but it always throw exception when open the template.
error message: 'exce..vsto_ae2ff0e19d548faf_0001.0000_bc4bb0e76797a3d0ExcelTemplate1' could not be found. Check the spelling of the file name, and verify that the file location is correct.If you are trying to open the file from your list of most recently used files, make sure that the file has not been renamed, moved, or deleted.'
research: I almost know it's because the .xlsx file didn't be copy to the installed location ( e.g. C:\Users\XXX\AppData\Local\Apps\2.0\XXX), and I also try to modify the manifest file in publish folder, but it's useless, and I also confused with this artile http://blogs.msdn.com/b/vsto/archive/2009/05/20/deploying-multiple-office-solutions-in-a-single-installer.aspx, how to include the vsto and .xltx file to the installed folder?
I guess you will have to build a window installer to do this. if still want to go via click once publish, you need add your windows installer as a prerequisite in VS.
I have a program that graphs a text file with some data in it. It works in the debug/release modes of VS 2010 C#. I'm using the .Net and Aforge frameworks. In my references is AForge.Math and the System.Windows.Forms.Charting libraries.
When I run the executable in the ...bin/release folder it works completely, meaning that when I drag and drop my text file into my form a graph appears, as it should. However if I copy that release folder onto another computer the .exe runs but when I drag and drop the text file it doesn't plot. I just get a white blank form.
This is what the program should look like when it's working...
when it's not working it does something like this(so I've attempted to drag and drop a text file into the form) and I get something that looks like this....
I suspect that my problem comes from using the AForge framework. All the computers have the .Net so when the data is input the charting continues to work but the data that is being graphed comes from AForge which is not on the computer. Although I am not entirely sure.
You should copy all the DLLs that you find in your debug or release folder. But sometimes not all the DLLs appear there. If you are using a framework maybe is looking for these DLLs in the installation directory or the GAC.
In this case that AForge is an external dlls so you have two solutions:
Install AForge in all the pcs where you want to copy your program.
CopyLocal True: In the references, in each AForge DLL, get sure that CopyLocal is true. Check this link for help on setting up CopyLocal=true. Then these DLLs will appear in your debug/release directory so when you drag all the references will work. Get sure that you copy all the files inside of debug/release folder, specially .dll, .exe, .config. Once you have it working maybe you can avoid copying .pdb files.
Personally I would try the last one.
Try setting all your references to be copylocal = true, this should put a copy of the dll in the bin\release folder so you can copy them to the other computer.
Open your solution in Visual-Studio and expand the references from the solution-explorer. It should show you a reference list of all DLLs your project is referring to. It must also include your AForge framework if it is used.
Now all you have to do is to ensure that the same set of DLLs are present on the target system:
Either in the exe's own path (This will be applicable for your custom DLLs such as AForge FW)
or
In the GAC (Global Assembly Cache) (Applicable for libraries that are installed such as your System.** framework libraries and MSOffice DLLs).
If something is missing, just copy the additional DLLs to your .exe folder on the target machine.
How to programmatically load an XLL file into Excel when it is linked to other DLLs.
Using c# winforms application + Excel Automation I’m creating Excel Application object. Then I’m using:
bool bXllLoadSuccess = _excelApp.RegisterXLL(_pathXll);
It is OK when XLL is self-contained. The problem occurs when it depends on other DLLs. Even when I put them into the same folder Excel doesn’t want to pick them up.
I tried to do following before loading the XLL but it doesn’t help:
_excelApp.DefaultFilePath = Path.GetDirectoryName(_pathXll);
I have tried this one as well:
Directory.SetCurrentDirectory(Path.GetDirectoryName(_pathXll));
Dependency walker shows no issues – all required files are in the same folder with the XLL.
Any ideas?
Thanks.
UPD: I tried copying all requried dlls into a folder and then added it's path to PATH variable. Didn't help :)
UPD2: I tried to change current directory for both c# app and Excel application object at the same time. Didn't help :(
I've built against the release profile and this creates an executable build within the release directory in my project.
How do I best distribute to clients from this executable? There are a lot of files within this folder which don't appear when installed through the installer, such as the mainifest and one called application.exe.xml (which is confusing when Windows hides the extension in Windows Explorer).
Are these all necessary? Can I just send the executable? Or will I need to send with all the files? Is there a way to build without all these files?
You must send the EXE file and any DLL file that you reference locally. If you use COM references and the like, you need to register them during the installation. The same thing for the GAC I think, but I haven't used that for stand-alone applications myself.
The application.exe.config file contains the application settings (a copy of app.config). If you don't use settings or the user doesn't typically care about them, you can omit the file, and it will use the default values you built the application with.
The vshost files are not needed (if you have them). They are used by Visual Studio's debugger. The .pdb files contain debug data used to facilitate DLL file to source matching. Unless you plan on attaching a debugger to the application, there is no point sending those.
Usually, in an XCopy deployment you have to deploy (literally copy all files deployment with no setup/installer program) the content of the output folder (like debug or release) without:
*.pdb - debug symbols
*.xml - xml documentation
?vshost? - Visual Studio hosting files
In fact, it anyway also depends on your specific application. As a developer, you need to know what you are producing; in case you are using an xml file which is not the result of the .NET documentation compiler, but a static file copied in the output folder, then do not forget to deploy it.
A last note: developers usually disable the option to hide file extensions in Windows Explorer ;-)
You need to understand what an installer does or why an installer is important.
An installer takes care of the basic environment. The installer can carry dependent assemblies/modules along with the application. It can also check if you need something before you run, like .NET on the target machine. It can also create the shortcuts on the desktop or start menu. Plus it also provides adequate options on the target machine to uninstall it.
If you wish to ship the executable alone, you might miss out some assemblies that the executable depends on. The target machine may or may not have the correct .NET version installed.
Use the program: HM NIS EDIT from HM Soft.
Build your project
Run NIS EDIT
Make a new script from the wizard (Ctrl + W)
Run all the steps
Select all the .dll and .exe files
Build a setup file
My task is to extract information from ppt file and compare with another ppt file. I have to use windows platform so i used excel and powerpoint's COM object.
After developing and testing the code in my computer when i exported the file into another computer it just failed. I started to debug in that file, and surprisingly debug was successful from first to last but as soon as click on the executable it fails.
I am totally *ucked up now cause inspite of updating excel dll files into those computers (which will serve the com support) it's not working. In every pc it gives different error message. I don't wanna work COM object anymore. It *ucks.
Can anyone suggest me any open source alternative in which i can read and extract information from Excel and Powerpoint files (both 2003 and 2007 format) ???
My preferred language is c# ........I got an paid solution (aspose) but i don't wanna go for that.
Any help will be appreciated. Just suggest me how can i deal with office files assuming ms office is not installed in my computer.
NPOI works well for Excel; I only know to use the built in, MS object library for PPT files.