C# expert and ASP.NET developer at heart, I find myself assigned now to an Office Add-In project. Luckily I have worked on several Excel Add-Ins in the past, but it's all blurry in my mind and I never had a chance to learn it in a well structured manner.
I was surprised to notice that SO and the whole Internet is lacking proper documentation for VSTO, Word DOM, OpenXML, etc. Lacking might be an exaggeration, but it's not abundant or well organized, that's for sure.
So what I'm looking for basically it's an overview, jump-start, or cheat-sheet, however you want to call it, containing a high level summary of the important parts of Office development.
PS: I will post my findings as well during my study.
My 2 cents
1) For latest WordArt in word, you would need OpenXML data to insert in Word. For Excel\Powerpoint, things are easier, you can just use interop.
2) Don't always trust the documentation. If you get an int instead of a bool return value, its mostly a value from MsoTriState. e.g. Bold property should return bool as mentioned here. But, instead it returns int. So, you have to cast it like "(MsoTriState)returnedBoldValue" to figure out what that integer actually means.
3) Installation can be a pain, consider using ready-made products like Advanced Installer(I found it cheaper than others). Others might be good or better as well.
4) Table styling can be a pain. Here is a list of the weird IDs you need to use it for Powerpoint.
5) TextFrame2 is still not valid for Word(even if the documentation might say otherwise). Its only available to Excel and Powerpoint. For Word, you have to use TextFrame.
6) WPF is not supported. But, I was able to get it working just fine after some research. You need to make sure to load resource dictionaries and they work fine as well.
7) Window Association was a bit of an issue(Parent - Child). WindowInteropHelper is your friend there.
For now, I will stop here. I will post some links later.
Document Level Architecture
Document
Template (essentially the same as Document from VSTO's perspective)
"Contained" by the Document.
Document contains the relevant information required to load the Add-In. Does not use Registry.
Application Level Architecture
Add-in
Directly plugged into and loaded by Office. Agnostic to Document. It is registered via Registry keys.
Ribbon
Supported by Visual Designer. It handles state automatically for you.
Ribbon X
It allows a much better customization. It's XAML like. No Visual Designer. It doesn't handle state. You need to handle state on your own, using callbacks.
Word DOM - Document Object Model
Application
Documents
StoryRanges
Range
Styles
Style
Windows
Window
Panes
Pane
It is nothing special, just another DOM, quite similar to the HTML one. However, it will take some time to get used with it and the information on the Internet is not as abundant as one might hope.
Manipulating the DOM
Directly
VSTO Controls: Windows Forms Controls, Host Controls
Windows Forms Controls
Powerful (supports .NET databinding for example) however they are not really part of Office so they will feel like a nut in a wall.
Host Controls (wrappers around the Interop Word objects)
Bookmark Control - old method, move on, nothing to see here.
XML Node & XML Nodes - deprecated. Removed in USA due to lawsuit.
Content Controls - The future! Support real data binding to hidden XML data field in the XML parts of the document.
Deployment
Click-Once - simple and fast. It adds the Registry entries for you. But it doesn't allow much customization. For example you can have a Click-Once project installed only to the current user.
Windows Installer, Installshield, etc. You need to add the .manifest and the .vsto files to the output. You need to add the registry keys.
Related
I cannot seem to understand if I need Microsoft.Office.Tools.Word and how to get it. I know that it works together with Microsoft.Office.Interop.Word as seen in this article, for example:
Visual Studio extends the Microsoft.Office.Interop.Word.Bookmark
object by providing the Microsoft.Office.Tools.Word.Bookmark host
control. The Microsoft.Office.Tools.Word.Bookmark host control behaves
like a native Microsoft.Office.Interop.Word.Bookmark, but has
additional events and data-binding capabilities. You can bind data to
a bookmark control on a document in the same way that you bind data to
a text box control on a Windows Form. For more information, see
Bookmark Control.
and that it enables you to add controls to a word document here, but I am not sure what the added value is (or if I need it).
I am developing an application that will generate a report of cyber security risks in a company (with primarily text and tables), and I am wondering what I have to use to make sure I can create my report properly (Microsoft.Office.Interop.Word at the least).
Also, I do not really understand where to get the Microsoft.Office.Tools.Word from. I included the Microsoft.Office.Interop.Word from NuGet easily, but I cannot find the other one in either NuGet or the Reference Manager. Because of this, I can not play around with this extra functionality and determine whether I need it in my project or not.
If you need more detail about my project to answer this question, feel free to ask.
No, you don't need to do Office Interop. Note that doing Office Interop requires you to have Office installed, also on the PC where you finally want to use it.
For a DOCX report, there are libraries like docx by XCeed (formerly a Github repo by the same author of docx on Codeplex) which can do things a lot easier. However, not all features might be supported.
We have a 3rd party component that takes INPUT as an .xsn (InfoPath2007) file and gives a pre-determined output. It was all fine until one of our client decided not to use MS-InfoPath anymore and as such even our 3rd party component is not able to function as we are not able to create xsn files (which were created by a human-InfoPath user till now, until InfoPath was discontinued in their group)... so the challenge for us is to create these SIMPLE (textbox, dropdown, date-picker and check-radio-box controls) InfoPath like forms -- .XSN files programmatically. Is this possible? Are there any APIs or Object-model based functions that can be leveraged for this task. Our team is predominantly C# developers. Our current analysis reveals that files pertaining to manifest, XML, J-scripting parts of .XSN might be achievable after some careful coding... however XSL (part that is associated with layout) seems to be a big gamble. Any pointers on this subject will be greatly appreciated.
UPDATE (as the problem statement does not seem to clear yet):
We do not want to convert InfoPath form into any HTML or alike format.
NOW here, we need to create some simple (pre-determined control-types with their known data) InfoPath forms programatically in .xsn file format. We want this to be done programatically, because earlier it was being done by a human-client who no longer subscribes to InfoPath-license and hiring another human for doing this is ruled out for various HR-reasons. So this "programatically"created xsn-file is fed it into this 3rd party component. Then this 3rd party component reads through the various parts inside the xsn-input and manipulates on it, into an output custom-file-frmat such that the custom 'workflow-component' keeps working further ahead... so hope you get the bigger picture now. Now an xsn file is essentially a CAB file consisting of many parts-components like manifest, xsL, xsD, xmL, images, jScript etc. So now if I have a winforms or ASP.NET webform... is it possible to write some component (using InfoPath object model or APIs) which can read through the UI-controls of this winform and then come up with the essentials that need to go into xsL, xmL, manifest etc so as to "collectively get compressed" into an InfoPath form!!!
Yes it is possible to Automatically create InfoPath Template Forms. The XSN is nothing but a cabinet file (.CAB) having the extension renamed to .xsn.
To further understand what are the contents of CAB file and what do they do, please follow the link:
A beginner's guide to forms and form templates
Following are the links that shall help you further.
Microsoft Cabinet Software Development Kit
A relevant Q&A to open CAB through C# program
I need to create a simple application that would generate reports based on database data and some user input. I have vast C/C++ experience, but for this project we had to choose C#.
I want to avoid using 3rd-party components that would require installation on a client machine as much as possible. Thus, I would like to avoid using even the features provided by MS Office (I could have used an XLS template, just like my predecessor did, but it doesn't look like a way to go; anyways, my predecessor's sources are long lost, which is probably good, since it is a roughly 10-years-old VB monstrosity that crashes every now and then). The same goes for crystal reports and whatnot.
My current idea is to build HTML tables (using an HtmlDocument) on the fly, to present them to the user (using a WebBrowser) and to print them. Is it a right way to go? Are there any simpler/more robust/better approaches? What are the possible pitfalls?
Building tables on the fly would work. I use that technique every so often, but it seems like a hack to me. I only use it because quite often, the business need requires "good enough" and quick turnaround as opposed to "beautiful".
I'm going to preference what I'm about to suggest bysaying that I have a strong bias against 3rd-party components myself.
I flat out refuse to use them in most cases and will go out of my way to come up with another solution, because I've been burned on upgrades/licensing too often.
That said...
Fortunately, with .NET not all 3rd party components need to be installed to your clients PCs. With XCOPY deployment, often you can just reference a .DLL or a project in the solution ans specify the "Copy Always" or "Copy if newer" option to just include the dll (or resulting dll if you're referencing a class library project) and as long as the .dll is present in the same directory as the executable, the 3rd party component works.
With all of that in mind, there's a project that I've used to print a DataGridView from Windows Forms at CodeProject. This is one that you can get the source for, reference it, and use it without having to actually install anything at the client. I've used it in more than one app, and it's one of my favorite tools.
It will print ONLY the DataGridView, but it prints it exactly as it appears on screen, so if that's what you want, I'd recommend at least checking it out.
As a third option, you could consider using ASP.NET. If you're going to be generating HTML, it's just as easy (easier actually) to do it using ASP.NET than in a WinForms app. Using ASP.NET you get Repeaters, ListViews, etc, all of which make the reports easy to create.
I've got more than one real-world app that is primarily a WinForms app but has an associated reporting site.
For example, I have a WinForms app used for scanning coupons accepted at our retail locaitons. It's a WInForms app because I need to interact directly with the scanner on a COM port. However, for the reporting portion, I set up an ASP.NET website. In the WinForms app it's very simple to create a reporting menu option and point to the pages. Our users generally don't even think about the fact that this is two distinct applicaitons. They see it as one - their Coupon Scanning app.
The point of all that is that it's usually possible to do things with any given tool, but it's far easier to use the tool that is meant for the job. If you're going to be generating HTML reports, ASP.NET is a better tool than building the reports manually, and if you need to have a WinForms app for most of the UI, you can still do that and use the website for the reports - using the best tool for each task.
Maybe you would like to check RazorEngine, to create your HTML templates.
I recommend you Razor engine to render html, it is more flexible than working with HtmlDocument objects.
You can create a file with your report template, and then parse it sending a Collection of your report rows objects.
Every week I produce a word document with some copy, tables and charts from various sources on our network.
It can take a bit of time and sometimes I make mistakes or forget stuff that should go in. I want to automate this process as much as possible.
So basically I want to make a Word Template or Console App that when I open/run it it goes off and collects all this stuff and links it into the various parts of the document.
Assume I have to insert:
Some copy from another Word document
A PNG (pie chart)
Create a table from a CSV file
Have a standard Header and Footer with page numbering
I usually make a few changes to the copy in the document to highlight the highlight from the week.
Then I check it into a SharePoint where network users can open and view it.
I figure the thing to do is crack open VS2010 and make a Word Template project. I have never done this before and I wondered what traps there are or if its even an appropriate way to solve my problem.
My other option would be some power-shell but i'm no expert there either.
I'd be pretty comfortable writing console apps so I might end up doing it that way.
Help/Advice appreciated.
I would approach this problem by breaking down the individual steps as you would perform them if you were sitting in front of a blank Word document. Then automate it using the object model. There's a little bit of a learning curve, but once you get past that you'll be addicted to automating Office. Office is quite a powerful platform. Most of what you can achieve via the User Interface can be done programatically. I do quite a bit of automation with Excel. The code is fairly intuitive...its things like worksheet.Range["A1"] = "abcd" (setting cell A1 = "abcd").
here are some pointers:
http://support.microsoft.com/kb/316383
http://msdn.microsoft.com/en-us/library/ee861527.aspx
If you go through the tutorial in the first link, you'll get the gist of it. What's great is that you can use the debugger to step through your lines of code. As each line executes, you can see the results on the Word document. I've never used a Word Template project, so I can't speak for the pros/cons there. Going the object model route, you just have to articulate what you want to have happen, break it down into the individual steps as you would perform them, and then code it up. If you get stuck, likely someone else has blogged/posted about how to make something happen. Google will find a solution very quick. Good luck!
You have lots of options:
automate Word
do it as a macro (dotm)
create your document using Open XML SDK
VSTO
You are probably best off doing it using a macro first, though this is old VB6. The techniques you quickly learn there translate pretty well into the other approaches. Open XML SDK has the virtue of not needing Word to create the document.
I have developed Word 2007 VSTO in VS2010 using C#. I want to be able to receive notifications about some of Document's collection changes, e.g. InlineShapes. I am also eager to intercept (be notified of) Insert/Picture or when a file is being dragged and dropped onto a Document. Is that possible?
I have spent a significant time looking for solution and searching resources everywhere but to no avail. It seems Outlook allows more flexibility in this area.
No, not possible. Word doesn't expose any events like that. The best you can hope for is to inteercept the DocumentChanged event, and try to ferret out was was changed based on the location in the document.
That won't be particularly easy though.