I'm trying to create a Shared Addin using VS 2008 for Office XP (Excel to be precise). However, after creating the project in Visual studio and changing the references to Office XP (apart from Extensibility which I don't seem to be able to find a copy for office xp) and adding excel.exe to the references as well. I now don't seem to be able to get the addin to install on any computers.
Does anyone have any guides on writing Office XP addins using VS 2008 (Com Addins I might add)?
Does anyone know the reference that I'm meant to have or things prior that I'm meant to have installed on the pc?
I have three test pcs, this one has office xp, 2003 and 2007 on it and I can write an addin using 2003 references that runs on this but no other box. One with just office xp on it but also office xp PIAs installed and .NET and another one just with office xp on.
Any help would be very much appriciated.
I found the problem with this in the end.
The problem came from a KB entry 908002. Unfortunatley, to run the fix you need Visual Studio 2005 and Office 2003 installed otherwise it won't deploy the fix and so I had glossed over this quite a few times. In the end I found an old copy of VS2005 and Office 2003 on a spare machine, installed the fix, created an installer and tried it on a machine with Office XP and everything worked fine.
There are two fixes that are needed for this to work on any machine with Office XP:
extensibilityMSM.msi - installs the extensibility.dll
lockbagRegKey.msi - adds a fix to a registry key
I couldn't find these to be downloaded seperately from the KB908002 fix but I have copies locally.
After applying these fixes it was easy to use COM Addins like using VSTO and it took me less than an hour to write the actual code. I'm not looking for a way to include these in my MSI installer as prerequesites.
Any questions chuck them in a comment and I'll try and update asap.
You need the PIAs installed as a prerequisite. Does the addin install at all, or fail at installation? An add-in misbehaving at startup may be banned by the host application (Excel). You can reneable it in the Add-in settings dialog in Excel.
#PintSizedCat - Here is a link to a msdn blog that shows how to extract the msi's without having VS2005 installed.
See the section "Building the Shared COM add-in setup project" - use the command line:
vs2005-kb908002-enu-x85.exe /T:”C:\Test” /C
For us it was Excel 2003 with .Net 2.0 and the extensibility.dll was missing. I don't think VS2008 / VS2010 have this as a prerequisite. The dll is not redistributable (According to this blog - see the "The Answer" section) - you must use the msi to redistribute it.
Related
The solution is very simple but impossible.
I have office 2010 and office 2012 installed, VB6 fails to create a Word application object giving me no more than just a message saying that the DLL is not registered.
All attempts to remove and restore the DLL using the installer or third party DLL fails.
After removing everything office related and only installing office 2010, the application object gets created successfully. But this is not a viable solutions for our customers: we can't have them removing their Office suites for this.
Is there any other way?
I had a similar issue on my dev machine with two versions of office. Cast your eye over this article from Microsoft support they mention the /regserver command line option. The article is Office automation when multiple versions of Office are installed. By the looks of it I don't think you can force it to pick one version or the other but the /regserver will help you in your dev environment.
I'd like to find the installation path of Office 2013 programmatically.
I saw in this discussion that the method working for Office 2007 and 2010 (looking in the HKLM\SOFTWARE\Microsoft\Office\14.0\Common\InstallRoot registry key) doesn't work anymore for Office 2013 and that the best way is to look into the registry keys
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{91150000-0011-0000-0000-0000000FF1CE}
for Windows 32-bits or
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{91150000-0011-0000-0000-0000000FF1CE}
for Windows 64-bits.
Is this supposed to work on every computer and for all versions of Office 2013 (Small business, Professional, etc) and Windows (7 and 8)? Or is there another solution?
You are almost there.
You can check uninstall registry key to get office install path.
As you mentioned registry key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{91150000-0011-0000-0000-0000000FF1CE}
{91150000-0011-0000-0000-0000000FF1CE} is like a product guid, you can treat it as a pattern to retrieve office path, I think they will be same installed on win7 or win8.
However, about different office version Small business, Professional... The guid may be same or different which depends on office implementation, you need to double confirm.
I am currently preparing an application in Visual Basic, mostly targeted on systems with .NET 2 installed and office 2003.
Moreover, as the systems are corporate ones, they need administrstion rights, so I had in mind an app that does not need to install anything (or register).
The application uses an external ocx, an axwebbrowser ocx and an excel interop.
The first problem stands because a user cannot run the application as it crashes, seeming because cannot find on his system ahdocvw.dll. is there a way to install for example a redistr package that includes the axwebbrowser system xomponent? At least to append it on the clickonce setup.
Second, in case that the user does not have the required framework, I would like to add on the Clickonce prerequisite box, the option for .NET 2 and office 2003. Right now, VS 2010 has only available .NET 3.5+ and Office Pia 2007.... could you suggest to me on how to proceed?
I'm trying to get started with building my own webparts, planning to follow this MSDN article.
I've downloaded Visual C# 2010 Express - I'm not quite at the point where I feel comfortable dropping 1000 big ones yet, and I installed Visual Web Developer 2010 Express via the WPInstaller.
Following through the tutorial, aside from the fact that I don't get the option to create a "Web Control Library", a gap I filled with this article, I can't seem to find the sn.exe tool (or the "Visual Studio 2005 Command Prompt"!).
I know it's not quite a direct programming related question, but I can't even get the thing going yet!
Any help is appreciated.
Thanks
EDIT:-
I think I may be jumping the gun quite considerably, I wrote a simple hello world example and tried to build it but it doesn't have any references to the Microsoft.SharePoint packages and they don't appear in my lists.
Am I understanding some more research I've done (namely this) correctly, in that I have to actually have a full installation of actual SharePoint on the machine I'm developing on?
sn.exe is part of the .Net Framework SDK tools - not actually part of Visual Studio.
If you've got the SDK installed (which I think you must have if you're using VS) then it will be in a directory such as (depending on which version of .NET SDK you've got installed)
c:\program files\microsoft.net\SDK\v2.0\Bin
You can develop SharePoint web parts with VS express but you won't be able to use extensions like VSeWSS which can make your life a little easier.
You don't have develop on a machine with SharePoint installed upon - you can just copy the Microsoft.SharePoint.dll assembly from a machine with it installed on and reference it in your project.
There are pros and cons to developing on a SharePoint machine.
Its easier to get started -
especially debugging locally rather
than remote debugging.
Harder to be
sure that you're code will work a
'real server' - are you sure you
don't have any dependencies that may
not be installed.
Harder to work with
multiple versions of SharePoint (2007
WSS and MOSS and 2010 foundation,
server etc).
If you do want to work with a locally installed SharePoint then
You can install windows server OS with SharePoint and Visual Studio.
there is a hack for installing SharePoint 2007 on vista (referenced in the SO article you link to)
you can install SharePoint Foundation 2010 on Windows 7 (but I am not sure what the licensing restrictions are - is this maybe something thats given through MSDN?)
If you decide to go with the remote server installation then save yourself some grief and use virtualization such as VMWare Server, Virtual PC or Hyper-V.
If you are doing SharePoint development trying to reference the Microsoft.SharePoint namespaces you need to have SharePoint installed on the machine if you want to do things like debugging, etc. For SP 2010 you CAN install SharePoint on a Win 7 machine. For previous versions of SharePoint, you will need to setup a Server that is Server 2003 or Server 2008 (you can't install SP 2007 and earlier on client machines). Generally this is a Virtual Machine for developers.
Having said all of that, there are relatively few reasons you need SharePoint to develop a WebPart. The vast majority of the WebPart functionality is part of the System.Web.UI.WebControls.WebParts namespace. Even if I am accessing SharePoint data, I generally use the ASP.NET web part.
If you are trying to use the new SharePoint VS 2010 functionality to create Visual Web Parts, etc, then you will need to install SP 2010, since that functionality is not supported in earlier version of SharePoint.
John
We have an issue with an Outlook 2007 AddIn (created on a Windows 7 development machine with Visual Studio 2008/VSTO).
It installs with the MSI installer on these machines:
- the development machine
- a Windows XP machine
Install initially succeeded on a Vista machine, but after installing an updated version of the AddIn, it gets disabled when starting Outlook. We suspect it might be related to how Vista handles security.
Have anyone encountered issues specific to installing VSTO AddIn on a Vista machine?
(Please note that the AddIn in our case gets installed alright, but is 'just' disabled when starting Outlook.)
The add in might be throwing an exception.
An unhandled exception causes the add in to be disabled.
We hit this issue on some random machines and after much head scratching, it turned out that Office.Interop was not installed on the client. We had assumed it would be installed with Office 2007 - which it appears to be in many cases.