I have outlook add-in which i have developed in C# (Not a VSTO application).
There are 4 projects in my solution :
Project1 (Add-in project)
Project2 (Class library)
Project3 (Shim Project)
Project4 (Class library)
Here are configurations of it :
Project1 (Platform : Any CPU)
Project2 (Platform : Any CPU)
Project3 (Platform : All Platforms)
Project4 (Platform : Any CPU)
I have WIX tool to make installer of it & Here is the snap of configuration manager.
NOTE : Project1.bootstrapper,Project1.setup & Project3 Doesn't shows option for 'Any CPU'.
I am making installer by building my solution in Debug/Release|Any CPU & Debug/Release|x64. But in this case, My add-in is working only in 64bit outlook. In 32bit outlook, Its giving me error "Run time error occurred. COM add-in not loaded". And While i am installing this add-in for 32bit outlook, Installer showing me message "Add-in (x64) Installing..." instead of "Add-in (x86) Installing...".
If i am buidling my solution in Debug/Release|x86, Then add-in is loaded on 32bit outlook. But this time not loading on 64bit outlook. While i am installing add-in on 64bit outlook, Installer showing me message "Add-in (x86) Installing..." instead of "Add-in (x64) Installing...".
Can anybody help me : How to make installer that can work on both architecture of outlook..?
Related
I need to build VS2010 C++ ATL project on CI server with no VS2010 installed.
The project can be successfully built on developers machine with VS2010 installed. But VS2010 cannot be installed to CI servers because that requires a license.
So, for now I'm trying the following approach:
Installed VS2010 Express
Installed Microsoft Windows SDK for Windows 7
Installed Windows Driver Kit (it includes ATL and MFC)
Although I have ATL headers and libs installed on the CI machine, I'm getting the following errors:
error C2039: 'AtlSetPerUserRegistration' : is not a member of 'ATL'
error C3861: 'AtlSetPerUserRegistration': identifier not found
I compared atlbase.h headers from VS2010 installation and from WDK. They are different:
- atlbase.h from VS2010 installation does have AtlSetPerUserRegistration definition;
- atlbase.h from WDK installation does not have it.
That causes an error mentioned above.
The question is: how to configure CI build machine for building ATL projects without installing VS2010?
Update:
Checking atldef.h file I found the following:
VS2010 version has the line:
#define _ATL_VER 0x0A00 // Active Template Library version 10.00
and WDK version has the line:
#define _ATL_VER 0x0800 // Active Template Library version 8.00
So, WDK ATL version differs from the VS2010 ATL version. That's why they're not 100% compatible.
Now the question is: How to get ATL v10.0 on the build server without having VS2010 installed?
In case if anyone else meets the same issue, here is a workaround:
The required version of ATL is available on developers machine with VS2010 installed (e.g. VS2010 Professional).
It is located in the folder %VCINSTALLDIR%ATLMFC.
By default it is c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
Folder ATLMFC can be copied to the build server by hands into %VCINSTALLDIR%, where VS2010 Express is installed. And that makes build server able to build VS2010 ATL projects without installing VS2010.
Though this is a workaround. And I'd like to see better solution if any. So, I'm not accepting my answer.
I am trying to add unit tests to a sharepoint solution in VS2010. I have a test project but I cannot retarget the project to .Net 3.5 even after installing SP 1 for VS2010. Please advise.
Here are the steps that worked for me to make Unit tests work with Sharepoint:
Install Visual Studio 2010 Service Pack 1
Create a new C# unit test project
In Project Properties change Application ->Target Framework to 3.5 and Build -> Platform Target to x64
In Test - Edit Test Settings - local testsettings - Hosts tab : change run tests setting to "Run in 64 bit process on 64 bit machine"
Regards
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?
Our installer generates a bootstrapper (setup.exe) and a MSI file - a pretty common scenario.
One of the production machines reports a strange problem during install:
If the user launches the bootstrapper (setup.exe), it reports that .NET 3.5 is not installed. This happens with account under administator group. No matter if they launch it as administrator or not, same behavior.
the application installs fine when application.msi or OurInstallLauncher.exe (see below for explanation) is started directly no matter if run as administrator is applied.
We have checked that .NET is installed on the machine (both 64bit and 32bit "versions" = under both C:\Windows\Microsoft.NET\Framework64 and C:\Windows\Microsoft.NET\Framework there is a folder named v3.5.
This happens on a 64 bit Windows 7. I can not reproduce it on my development 64 bit Windows 7. On Windows XP and Vista, it has worked without any problem for a long time so far.
Part of our build script that declares the GenerateBootStrapper task (nothing special):
<ItemGroup>
<BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
<ProductName>Microsoft Windows Installer 3.1</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="Microsoft.Net.Framework.3.5">
<ProductName>Microsoft .NET Framework 3.5</ProductName>
</BootstrapperFile>
</ItemGroup>
<GenerateBootstrapper
ApplicationFile=".\Files\OurInstallLauncher.exe"
ApplicationName="App name"
Culture="en"
ComponentsLocation ="HomeSite"
CopyComponents="True"
Validate="True"
BootstrapperItems="#(BootstrapperFile)"
OutputPath="$(OutSubDir)"
Path="$(SdkBootstrapperPath)" />
Note: OurInstallLauncher.exe is language selector that applies a transform to the msi based on user selection. This is not relevant to the question at all because the installer never gets as far as launching this exe!
EDIT: It displays that .NET 3.5 is missing right after starting setup.exe and proposes to install .NET 3.5. When the user agrees with the install, the .NET 3.5 installer says that .NET 3.5 is already installed and the MSI installer proceeds. If they choose to not install .NET 3.5, the installation ends.
Has anyone seen this behavior before?
This seems to be a bug either in Bootstrapper or in Windows 7.
Solution:
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35\en\package.xml
has to be tweaked on the build machine, because default German Windows 7 installations do not have this key present:
<RegistryCheck Property="DotNet35InstallSuccess"
Key="HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\1033" Value="Install" />
As a result, the installer reported that .NET 3.5 is not installed on the target machine (German Windows 7).
In order for the setup to detect installed .NET correctly,
the C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35\en\package.xml
file must be tweaked as following:
\1033 must be removed from the registry check key:
<RegistryCheck Property="DotNet35InstallSuccess"
Key="HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5" Value="Install" />
The fact that the MSI installs without problems is not surprising, considering that it is only the bootstrapper which concerns itself with installing .NET 3.5. MSI packages don't need .NET in order to be installed (unless you use custom actions implemented in .NET assemblies, or register .NET assemblies in the GAC).
Uninstall and reinstall .NET on the machine that has the issue. It is most likely just a .NET install that has been corrupted somehow.
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.