-
Monday Office and SharePoint 2010 Beta were released to MSDN/TechNet subscribers. Today it was announced at PDC that these are available to the rest of the public! Come and get it…
Office 2010 Beta
SharePoint 2010 Beta
These Betas are compatible with Visual Studio 2010 Beta 2 which was released to the public a few weeks ago. We’ve also started a series on Channel 9 on SharePoint development in Visual Studio so check that out starting with:
Overview of SharePoint Development in Visual Studio 2010
Also check out…
Office 2010 resources
SharePoint 2010 Resources
And stay tuned here for more posts on Office Development with Visual Studio 2010!
Enjoy,
-Beth Massi, Visual Studio Community
-
Office and SharePoint 2010 are available for MSDN Subscribers today:
MSDN Subscribers: Office 2010 Beta is here.
MSDN Subscribers: Microsoft Sharepoint 2010 Beta is here.
These versions of Office and SharePoint are compatible with the Visual Studio 2010 Beta 2 that was released a couple weeks ago. Check out these resources and please let us know what you think.
Office 2010 resources
SharePoint 2010 Resources
Also keep an eye out on Channel 9 today for an overview of some of the Visual Studio 2010 tools that make Office and SharePoint Development easy.
Enjoy!
-
If you missed it, Office announced a compatibility program to help IT and developers who have built add-ins make a seamless upgrade to Office 2010. We want you to have a successful and seamless migration to Office 2010 for your VSTO solutions. The program provides tools for environment assessment, code scanning and remediation assistance, and an update to the document conversion tools introduced with Office 2007.
Check out Michael Kiselman’s post for more details on the program that will be available in early December.
Enjoy,
-Beth Massi, Visual Studio Community
-
I have previously posted how you can specify various properties for a VSTO solution like the Publisher and Product Names by tweaking a few files in Visual Studio 2008.
With Visual Studio 2010 (Beta 2) you can edit these properties directly through the Publish Page. All Office projects in Visual Studio 2010 now have an Options button on the Publish Page, which allows you to spet these properties.
The Publish Options dialog is similar to the ClickOnce publish options dialog for other types of projects, but this dialog only displays the options applicable to Office projects.
Here is what these properties mean:
Publisher Name – The name of the Publisher as displayed in Programs and Features
Product Name – The name of the Solution as it will show up in the Programs and Features (Add Remove Programs Entry)
Support URL – A URL which End Users can visit to get support for this particular solution. The support URL shows up as a clickable link for the product name during the installation trust prompt.
Solution Name – (Friendly Name) This is the name of the Add-In as it is displayed in the Office Add-ins dialog.
Office Application Description – The description of the Office Add-in as displayed in the Office Add-ins dialog.
Add-in Load Behavior – Specifies whether the add-in should load when the Office Application Starts up or whether it should load on demand when the end user tries to interact with it. By default all add-ins are set to load at startup of the Office Application but if you care about Office startup performance and don’t want your add-in to be running all the time then you should consider loading it on demand.
Andrew Whitechapel has a post on how an Office add-in can be demand loaded using different loadbehavior values. Previously you had manually update the ClickOnce manifests with the appropriate load behavior value. With Visual Studio 2010 you can set the option to load the add-in on demand and the loadbehavior will be automatically set to 16 (connect first time) –> Load the add-in on startup for the first time and then load on demand from then on.
Loading an add-in on demand can help improve the startup performance of the Office application. It can also reduce the application’s working set as the add-in is not loaded in memory until the end user interacts with it. Setting the add-in to demand load is a good option if your add-in has UI based triggers, like a Ribbon item that the end user can interact with to load the add-in. However demand loading may not be a good option if your add-in is needs to listen to application events like opening a document etc all the time the application is running. So if your add-in doesn’t have to run all the time, then setting it to Load on Demand is a good option to consider.
Lastly, there is an interesting side note for those of you who may have changed their VS 2008 based project files based on my previous post. If you updated the project file using the same property names as that mentioned in the post, you can migrate that project to VS 2010 and continue using those property values. You no longer need the custom targets file as that functionality is now directly available in the Visual Studio common targets.
For more information, see Publishing Office Solutions.
Have fun with Visual Studio 2010 Beta2 and let us know your feedback!
Saurabh
-
One frequent customer question is about how to deploy an application and all of its prerequisites in a single .msi or .exe file. This question applies whether you are deploying any of the following:
- Microsoft Office 2003 solutions with dependencies on .NET Framework 2.0, Visual Studio Tools for Office 2005 SE runtime, Microsoft Office 2007 primary interop assemblies.
- Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 , Visual Studio Tools for Office runtime 3.0, Microsoft Office 2007 primary interop assemblies.
- Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 SP1, Visual Studio Tools for Office runtime 3.0 SP1, Microsoft Office 2007 primary interop assemblies.
- Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 SP1 Client Profile, Visual Studio Tools for Office runtime 3.0 SP1, Microsoft Office 2007 primary interop assemblies.
- Really, any WinForms/WPF/console/whatever app with dependencies on .NET Framework, SQL Server Express, SQL Server compact, Visual C++ runtime, Windows Installer, or anything else.
There are three concepts in deployment related to prerequisites: nesting, merging, and chaining or bootstrapping.
Nesting is the process of embedding a Windows Installer file (.msi) within another .msi file. However, the How to create a nested .msi package article has an important disclaimer.
The drawbacks of creating a nested MSI installation are listed in the same article.
- Nested Installations cannot share components.
- An administrative installation cannot contain a nested installation.
- Patching and upgrading will not work with nested installations.
- The installer will not correctly cost a nested installation.
- Integrated ProgressBars cannot be used with nested installations.
- Resources that are to be advertised cannot be installed by the nested installation.
- A package that performs a nested installation of an application should also uninstall the nested application when the parent product is uninstalled.
For these reasons, nesting is no longer supported.
Merging includes shared code, files, resources, registry entries, and setup logic to applications as a single compound file. Prerequisites available as a merge module (.msm) form can be added to a .msi file. For example, if a prerequisite is available as an .msm, you can add it to a Setup project in Visual Studio as shown in How to: Create or Add a Merge Module Project. However, merge modules cannot be serviced by the same owner as the .msi file, so it is difficult to fix issues in the merge module. Tao of the Windows Installer, Part 4 lists two cautionary notes:
- Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive
- Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame
For these reasons, using merge modules is not recommended.
Nesting and merging create a single file to deploy an application and its prerequisites, but these methods are not supported and not recommended. Thus, the answer to the question in the title is no: you cannot or should not deploy an application and its prerequisites in one file.
Chaining or bootstrapping is the process of checking for and installing missing prerequisites, including installing the application that is going to be used to install the rest of the prerequisites and application. You can use Visual Studio to generate a chainer/bootstrapper that is called Setup.exe. This program checks for and installs missing prerequisites before installing the application or Office solution.
If you are deploying an Office 2007 solution in Visual Studio 2008 SP1, the .NET Framework 3.5 SP1, Visual Studio Tools for Office 3.0 SP1 runtime, and Microsoft Office 2007 primary interop assemblies are already selected in the Prerequisites Dialog Box.
To learn more about how to install prerequisites in Visual Studio, see the following topics.
How to: Install Prerequisites on End User Computers to Run Office Solutions
How to: Install Prerequisites in Windows Installer Deployment
How to: Install Prerequisites with a ClickOnce Application
If the prerequisite package does not appear in Visual Studio, you can create your own bootstrapper package. After you create a product.xml file that describes the prerequisite and a package.xml files that includes locale-specific error messages, you can copy the bootstrapper package to \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages folder. For more information, see Creating Bootstrapper Packages.
Other tools besides Visual Studio: You can also use MSBuild and the GenerateBootstrapper Task to create a bootstrapper on a build computer. Alternatively, you can use the Windows Installer XML Toolset to generate .msi files and package prerequisites. For more information, see http://wix.sourceforge.net/.
For questions about bootstrapping, search for answers or post new questions in the ClickOnce and Setup & Deployment forum.
Happy deployment!
Mary Lee, Programming Writer.
-
Robert Green, VSTO MVP, has started a series of tutorials on building on Office 2007! Thanks Robert!
In this first of a series of tutorials on building applications on Office you’ll learn how to create an Outlook 2007 customer appointment management solution using Visual Studio 2008. This step-by-step tutorial also includes full source code in Visual Basic and C#. Check out the tutorial on the VSTO Developer Center:
Building an Office Business Application Part 1 - Scheduling Customer Appointments
If you’re just getting started with Office development in Visual Studio, this is a great place to start.
Enjoy!
-
Robert Hess posted an interview yesterday on Channel 9 with John Durant on Developing Managed Applications for Office 2010 in Visual Studio 2010. When you have 20 minutes you should check it out.
John provides some highlights as to what he’ll be showing in his PDC sessions, and some of the new features that developers can look forward to in Office and Visual Studio 2010.
Enjoy,
-Beth Massi, Visual Studio Community
-
I mentioned on my blog yesterday that SDN Magazine made an article I wrote back in May available online -- and since it’s all about using WPF & data in a VSTO solution I thought I’d post the link up here too :-)
Using Windows Presentation Foundation and Line-of-Business Data in Microsoft Office Clients
In this article I talk about how to expose Line-of-Business data via ADO.NET Data Services to an Excel client using WPF. Office solutions you build with Visual Studio are designed to work with Windows Forms controls but you can also use WPF controls in your solutions as well. Any UI element that can host Windows Forms controls in an Office solution (VSTO) can also host WPF controls using the Winforms ElementHost as a container.
Using WPF controls in Office allows you to think out of the box and provide world-class data visualizations that are not possible with Windows Forms controls. And you can do it easily in an instantly familiar end-user application like those in the Office family. But what if you don’t have any fancy data visualizations? Even the simplest controls that display data are often better off as WPF controls in Office applications because they better match the UI styles used in the latest versions of Office. Using WPF can make your add-ins look built into the Office applications themselves, providing a better user experience.
This article describes one piece of the Northwind Office Business Application (OBA) sample we created in the beginning of the year so if you’re just getting started in OBA development with Outlook, Word, Excel and Sharepoint I’d suggest reading these as well:
- OBA Part 1 - Exposing Line-of-Business Data
- OBA Part 2 - Building and Outlook Client against LOB Data
- OBA Part 3 - Storing and Reading Data in Word Documents
- OBA Part 4 - Building an Excel Client against LOB Data
- OBA Part 5 - Building the SharePoint 2007 Workflow
The full sample application, built with Visual Studio 2008, is here: http://code.msdn.microsoft.com/OBANorthwind
Hmm… I’m thinking a part 6 on deployment of this baby would be a good follow up….
Enjoy,
-Beth Massi, Visual Studio Community
-
The Visual Studio team is designing the runtime components for Office 2010 so that your Visual Studio Tools for Office 2005 and Visual Studio 2008 .NET addins, document solutions and spreadsheet solutions will run on 64-bit Office 2010. These runtime components will ship with Office 2010, so your end-users won’t even have to download a new runtime! How easy is that? There are a few rare exceptions that I’ll discuss in this blog entry.
The miracle of managed code allows you to write C# or Visual Basic .NET code that compiles to “Any CPU” using the Compile setting in your Visual Studio project. Your code compiles to MSIL with Visual Studio, and then at runtime it gets JIT compiled to the correct chip set, either AMD, Intel, 32-bit or 64-bit. The first exception to this wondrous technology is the oldest versions of .NET Framework 1.0 and 1.1 will not enable this 64-bit transformation.
The other thing to lookout for is calls to process invoke (p/invoke) in your code. If you try to call native API methods using p/invoke you could have issues with your VSTO solution running properly on 64-bit Office 2010.
You will have problems if your code makes deliberate calls to p/invoke a Win32 API that does not have exactly the same signature (method name, parameter list, and DLL name) of an equivalent Win64 API. This is true for any solution you write regardless of targeting Office as the platform. You can find a ton of information in MSDN and blogs by such luminaries as Scott Hanselman about writing Windows API calls so that they will run on either 32-bit or 64-bit Windows. Here is a generalized code snippet for handling cases where the method name or the DLL name is different:
//YourFunction has the same name, parameters, and DLL name in 32bit and 64bit
YourFunction();
Import("LIBRARY", EntryPoint = "YOURFUNCTION", CharSet = CharSet.Unicode)]
private static extern bool YouFunction();
//In some cases, the method name is different in Win32 API and Win64 API,
//so use the following code block in stead of the above 3 lines of code.
if (Marshal.SizeOf(typeof(IntPtr)) == 4)
{
YourFunction32();
}
else if (Marshal.SizeOf(typeof(IntPtr)) == 8)
{
YourFunction64();
}
Import("LIBRARY32", EntryPoint = "YOURFUNCTION32", CharSet = CharSet.Unicode)]
private static extern bool YourFunction32();
Import("LIBRARY64", EntryPoint = " YOURFUNCTION64", CharSet = CharSet.Unicode)]
private static extern bool YourFunction64();
Resources:
Here are more resources to help you author your solutions today so that they will run without needing a recompile when your users install 64-bit Office 2010.
MSDN Library Visual Studio 2005 article on developing 64-bit Applications
MSDN Library Visual Studio 2008 article on developing 64-bit Applications
How to access the “real” x64 registry from a Win32 .NET Application – Part I
The Myth of .NET Purity, Reloaded
For migrating your really old apps with lots of native calls to .NET, try checking if your native calls have an equivalent .NET call:
Microsoft Win32 to Microsoft .NET Framework API Map
Interoperating with Unmanaged Code
Finally I should mention that this is my last post (for a while at least) on this blog because I am leaving Microsoft. I’m going to work on a charity project teaching robotics programming to high school kids in my “inner city” neighborhood for at least the next 6 months. The project is called Team Xbot! Keep an eye on these kids as they go on to good colleges and great jobs in the next few years!
Sincerely, Christin Boyd, Program Manager
-
Every once in a while, we learn of neat apps that have been created with the Office development tools in Visual Studio. In an Outlook 2007 add-in, Jake Ginnivan combined WPF and the Facebook API to respond to Facebook events from a Ribbon. In addition, this add-in works in Outlook 2010 and has been deployed with ClickOnce. He’s written about this in two parts:
Writing a Facebook event synchroniser for Outlook 2007+ Part 1
Writing a Facebook event synchroniser for Outlook 2007+ Part 2
If you have come across other VSTO apps, feel free to leave a link in a comment here.
Mary Lee, Programming Writer.
-
If you’ve missed them, Kathleen has been interviewing writers on various documentation teams on some of the new features going into Visual Studio 2010. Our own Mary Lee now has a couple video interviews posted on new VSTO features that you should check out:
If you like reading better than watching videos, here are the walkthroughs in the MSDN library:
For more resources and information on how to download the VS2010 Beta, visit the Visual Studio Developer Center.
Enjoy,
-Beth Massi, Visual Studio Community
-
A customer recently reported this bug when running their Shared Addin for Excel on French Windows.
Error: 0x80028018 (-2147647512)
Description: Old Format or Invalid Type Library
His solution worked great on English Windows, but gave errors in any other language. This is a known problem in Excel and there are a few workarounds that work depending on the way you’re writing your Excel Addin. Let me take you through the problem, variations on the problem, and different solutions depending on which Visual Studio project template you choose to start your Addin.
The bug was originally documented in a KB 320369 article, which gives detailed repro steps, explanation, and two workarounds with sample code. So why am I writing a blog post if the KB article covers everything? Three reasons.
- Because we’re fixing the problem in CLR 4 and I want to encourage you to use one of the recommended workarounds in your current solutions so that you’re ready when your users upgrade to .NET Framework 4.
- Also, there are parts of the KB article that are a bit confusing, so I’ll try to add some color commentary to help explain what’s causing the problem.
- And third, these problems do not occur if you use VSTO 2005 SE, VSTO 3.0 (which ships with Visual Studio 2008), or Visual Studio 2010. I’ll explain why and how later.
The KB article describes the problem:
Error: 0x80028018 (-2147647512)
Description: Old Format or Invalid Type Library
You receive this error calling an Excel method when the following conditions are true:
- The method requires an LCID (locale identifier).
- You run an English version of Excel. However, the regional settings for the computer are configured for a non-English language.
If the client computer runs the English version of Excel and the locale for the current user is configured for a language other than English, Excel will try to locate the language pack for the configured language. If the language pack is not found, the error is reported.
The quote from the KB article is accurate, but can be confusing. It is very difficult to determine if the Excel method you want to call requires LCID or not. The Primary Interop Assembly (PIA) does not indicate whether or not the LCID is needed, however VBA does not hide the need for LCID. Part of the reason why Excel hasn’t changed its methods is to maintain back compatibility with all the VBA code in the universe.
Fixed in VSTO
VSTO implemented a fix in VSTO 2005 Second Edition (SE). You can read more about this fix in Eric Carter’s blog post. The fix is also in all subsequent versions of Visual Studio 2008 and will be in Visual Studio 2010. You know you are using “VSTO” when you create a new Project in Visual Studio and select an Excel <version number> Workbook, Excel <version number> Template or Excel <version number> Addin. The fix was not implemented in the Shared Addin template in any version of Visual Studio. If you create a WinForms, WPF, Web or console application that calls Excel, then you will see this bug on non-English Windows.
Workarounds
If you are using the Shared Addin template, a WinForm, WPF, Web or Console application with any version of Visual Studio, then you should use the KB 320369 article to solve the problem.
The workaround is to write explicit calls to set the thread’s culture before calling into Excel. You can then reset the culture back to what it was before after you are finished calling Excel.
- Install the Multilingual User Interface Pack for your version of Office.
- Execute the Excel method or property by using InvokeMember so that you can specify the CultureInfo for the call. For example, the following code illustrates how you can invoke the Workbooks object Add method with "en-US" as the CultureInfo:
Dim oApp As New Excel.Application()
oApp.Visible = True
oApp.UserControl = True
Dim oBooks As Object = oApp.Workbooks
Dim ci As System.Globalization.CultureInfo = New System.Globalization.CultureInfo("en-US")
oBooks.GetType().InvokeMember("Add", Reflection.BindingFlags.InvokeMethod, Nothing, oBooks, Nothing, ci)
- Or, instead of the above bullet and code sample, set the CultureInfo prior to calling the Excel method, and then you can reset it after your Excel call:
Dim oApp As New Excel.Application()
oApp.Visible = True
oApp.UserControl = True
Dim oldCI As System.Globalization.CultureInfo = _
System.Threading.Thread.CurrentThread.CurrentCulture
System.Threading.Thread.CurrentThread.CurrentCulture = _
New System.Globalization.CultureInfo("en-US")
oApp.Workbooks.Add()
System.Threading.Thread.CurrentThread.CurrentCulture = oldCI
The .NET Framework 4 will solve this whole culture problem. Excel is not going to change its culture sensitivity because of the need to support backwards compatibility. Starting with CLR 4.0, when managed code calls into a COM component and an LCID is required, then the CLR will pass LCID = 1033. Note that this is how VBA passes LCIDs. This means that Visual Studio 2010 project templates for Excel Addins can stop wrapping all Excel projects with LCID proxy. In the future, when you use VS 2010 and .NET 4 to write your Excel automation programs from a Shared Addin, console, Winforms, WPF, or Web application, you won’t need to wrap your calls either.
-Christin Boyd, Program Manager & Misha Shneerson, Senior Developer
-
If you haven’t seen it yet, we’ve got a new article from Robert Green (MVP) up on the VSTO Dev Center. In this article, learn how you can use Visual Studio to build application-level add-ins that automate common Microsoft Office tasks. It’s a good introduction to Office development with Visual Studio so check it out!
Create an Application-Level Add-In to Automate Common Office Tasks
Enjoy,
-Beth Massi, Visual Studio Community
-
Visual Studio 2010 will ship with a 32bit version, and no 64bit version. My team built a very smart layer into Visual Studio 2010 to enable designers and debuggers that work with 64bit Office 2010 and 64bit SharePoint Server 2010.
For a good explanation of why the Visual Studio team chose to only build a 32bit version for the next release, you can find a blog post by Rico Mariani titled “Visual Studio: Why is there no 64 bit version? (yet)”
SharePoint Server 2010 will be 64-bit only. You can learn more about the requirements of Microsoft SharePoint Server 2010 on the SharePoint Team Blog entry “Announcing SharePoint Server 2010 Preliminary System Requirements” If you plan to build solutions for the next generation of SharePoint Server, then I recommend budgeting to purchase 64bit hardware.
-Christin Boyd, Program Manager, Visual Studio
-
Mary Lee recently posted a blog entry that describes Deploying Multiple Office Solutions in a Single Installer, complete with graphics to help you visualize the process. I recently interviewed Mary to learn more about this topic, and to have her give a demonstration of some of the tasks described in this post.
If you’ve often wondered who’s hidden behind that motorcycle helmet, be sure to check out the video!
See video: Deploying Multiple Office Solutions in a Single ClickOnce Installer
I will be posting additional interviews, demonstrations, and featured Visual Studio 2010 Beta 1 content on my blog: http://blogs.msdn.com/kathleen.
-- Kathleen
