Wanted to check if you could eventually get the controls-stuff working through NetOffice somehow, and if yes / possible, share some details please.
Was the approach suggested by geirg earlier in this thread of any use in this context?
Regards.
Any update on this issue? I have alot of problem when run project on Windows 7, Windows 8 x86.
Regards
Sorry for not write the reason late.
BUG is Not For NetOffice. I start a new trhead to monitor a variable which hold the COMObjects of Word, So that I can Dipose them when timeout.
I start the thread in DoConnection as:
private bool DoConnection(object Application, ext_ConnectMode ConnectMode, object AddInInst) {
if (_wordApplication != null)
return true;
try {
AssemblyResolver.Register();
//NetOffice.Factory.ProxyCountChanged += new NetOffice.Factory.ProxyCountChangedHandler(Factory_ProxyCountChanged);
//StartMonitor();
System.AppDomain domain = AppDomain.CurrentDomain;
log4n.Info(domain.BaseDirectory);
Step("Startup OK...");
Step("OnConnection 0" + Application);
_wordApplication = new WordAPI.Application(null, Application);
Step("OnConnection 1");
_commandBars = _wordApplication.CommandBars;
This code runs OK in WIN7, BUT in XP raise SEHException.
foreach (Application word_application in Application.GetActiveInstances())
{
foreach (Window window in word_application.Windows)
{
if (filename == window.Document.FullName)
{
//Do good stuff here
}
}
}
it doesn't work. Application xl = new Application();
List<Application> apps = Application.GetActiveInstances().ToList();
apps.RemoveAll(app => app.Visible == false);
return apps;
Actually apps contains 2 instances after Application.GetActiveInstances() but my filter on the visible property is not working whereas I have only one visble on my desktop.Did you find a solution?
This is how I persist a copy of the file from an open document.
http://blogs.msdn.com/b/pranavwagh/archive/2008/04/03/how-to-do-a-save-copy-as-in-word.aspx
http://stackoverflow.com/questions/8981118/how-can-i-save-the-contents-of-an-oleobject-as-a-file-in-an-automated-way
```
using System.IO;
using COM = System.Runtime.InteropServices.ComTypes;
using System.Runtime.InteropServices;
public static bool PersistFile(object underlyingObject, string newfilePath)
{
COM.IPersistFile pp = (COM.IPersistFile)underlyingObject;
pp.Save(newfilePath, false);
return File.Exists(newfilePath);
}
```
http://office.microsoft.com/en-us/excel-help/what-is-protected-view-HA010355931.aspx
create a NetOffice.WordApi.ProtectedViewWindow for your document.
```
//detecting if in protected mode.
NetOffice.WordApi.ProtectedViewWindow protectedViewWindow = Application.ActiveProtectedViewWindow;
if (protectedViewWindow != null)
{
return;
}
```
> Each boostrapper detects whether 32bit or 64bit Office is installed and calls either the embedded 32 or 64 bit msi installer.
What is your detection strategy. As a 64 bit computer can have a 32 or 64 bit install of an office app. A 32 bit office app cannot see into the ProgramFiles64Folder or System64Folder. Same goes for the registry hive. MS does some tricks with emulation of the hive based on if the process is 32 or 64 bit.
/////////
Is there any difference to your issue when installing on a computer that has never had your product installed vs one where you have installed/uninstalled/upgraded?
/////////
Had this issue when the Count value does not get incremented on upgrades. Suggest increment this count each build.
HKLM\SOFTWARE\Microsoft\Office\14.0\User Settings\SomeApp.PowerPointAddin
http://blogs.msdn.com/b/mshneer/archive/2007/09/05/deploying-your-vsto-add-in-to-all-users-part-ii.aspx
Newer versions of office use the user setting feature to populate key into the HKCU(curent user) hive.
When the office application starts the registry keys here will be populated into the users hive for use.
The one issue is the orphaning of HKCU addin keys. They are not removed by the installer nor office unless a delete is created.
Some great questions ekirk0 - let me expand to see if it shines some light on the problem:
1. 32/64 bit office detection strategy: The 32 or 64bit msi installer is launched depending on the detection of existence of PowerPoint Path from the 32 or 64bit branch of the registry - HKLM\SOFTWARE\Microsoft\Office\X.0\PowerPoint\InstallRoot\Path (where X is 12, 14 or 15)
=> There is no obvious issues here that I can find as the 32 and 64 versions are installed for new users without an issue. However for existing users the installer installs correctly, the registry entries are ready, DLLs are loaded as shown by Fusion, but addin errors after DLLs are loaded and therefore changes LoadBehavior from 3 to 2. Have I missed anything here?
2. Differences in new vs upgrades: The issues seems to be on installing a new version of the Addin when an existing version exists. This is mostly from the old "All User" VSTO version of the addin to the new Current User or All User NetOffice version of the addin. The Current User msi install (no admin permission required) deploys files to c:\Users and registry entries to HKCU, while the All user (Admin UAC) deploys to the Program Files ([ProgramFiles64Folder] for 64bit, and [ProgramFilesFolder] for 32bit msi) and HKLM registry. The "Current user" msi won't uninstall the old Addin as it requires Admin permissions, but even if the user manually does it themselves, there is still an issue. How can I find if something is cached or force the addin to look for the new version of the file in a new location? Maybe the MyAddin.DLL.Manifest Addin registry setting to force PowerPoint to find the location of the new files?
3. This is an interesting article that I hadn't come across in months of research and does show a nice mechanism to add a HKLM registry into the HKCU on startup. However, as I am successfully deploying the current user key to this branch, I don't really see any advantage. Is there something else that the UserSetting registry does here that I've missed?
I did notice the orphaning issue of addin registry branches on uninstall if DeleteUninstall = False, but as I set DeleteUninstall = True I changed the uninstall of the old msi within Orca to occur before the install of the new version. The result is slightly slower to install, but guarantees the registry branch will remain in tact no matter whether the old version DeleteUninstall is set to True or False, as the uninstall is done first rather than last.
Thanks
Maybe there is an issue with the com that isn't apparent. Make a simple vb/js script that loads your com object by name. Then execute a function of that com object. This will help you determine if this is either com object references messed up or something else. Make a version property to return some info.
```
var type = System.Type.GetTypeFromProgID("name of com class");
var obj = Activator.CreateInstance(type);
obj.Version
```
have you thought about using wix to build your msi also. vsto has its limitations especially if you have to bust out orca to change things.
So I have a word document this is not in protected mode but I want to open it in read only protected mode. I don't see how that works in code.
Try
_outlookApplication = New Outlook.Application(Nothing, Application)
Catch ex As Exception
Dim message As String = String.Format("Errore.{0}{0}{1}", Environment.NewLine, ex.Message)
MessageBox.Show(message, _progId, MessageBoxButtons.OK, MessageBoxIcon.Error)
End Try
If Not _outlookApplication Is Nothing Then
AddHandler _outlookApplication.NewMailExEvent, AddressOf NuovoMessaggio
AddHandler _outlookApplication.ItemContextMenuDisplayEvent, AddressOf ApplicationItemContextMenuDisplay
End If
here's the event handler:Private Sub ApplicationItemContextMenuDisplay(CommandBar As Office.CommandBar, Selection As Outlook.Selection)
messagebox.show("click")
End Sub
Any idea about where i'm wrong?