I have been browsing through the internet looking for some answers on my question. Basically, we are developing several Office/Outlook addins. And each addin type is installed via their manifests.
In modern systems, the following schema is used in their manifest :
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0"
xmlns:mailappor="http://schemas.microsoft.com/office/mailappversionoverrides/1.0" xsi:type="MailApp">
For older systems, we are using :
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="MailApp">
I was wondering, if older systems will have problems if I use the newer schema on them.
In short, does Exchange 2013 support this schema declaration? :
<<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0"
xmlns:mailappor="http://schemas.microsoft.com/office/mailappversionoverrides/1.0" xsi:type="MailApp">
Thank you.
The manifest with mailappversionoverrides should install on recent CU's for Exchange 2013 because of how the schema is defined in Exchange 2013. However, Exchange 2013 does not have logic to use or validate recent the more recent schemas added to the manifests. This means, for example, Exchange 2013 does not validate the new nodes, and OWA from Exchange 2013 will not make use of the new additions in the manifest. On the other hand, recent Outlook connecting to Exchange 2013 should be able to retrieve full manifest.
Keep in mind that some features and API require both Exchange and Outlook support, so those features would not work with Exchange 2013.
Also for reference on Exchange 2013 lifecycle: https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-2013-enters-extended-support-lifecycle-phase/ba-p/607811#:~:text=Exchange%20Server%202013%20enters%20the%20Extended%20Support%20phase,product%20updates%20due%20to%20time%20zone%20definition%20changes.
Related
I have Exchange on-premises server with version 2013
I wrote an Office add-on which I can install in Office365 account with manifest file with out any issues
But, when I try to install the same add-on from my Exchange 2013 OWA > Settings > Manage Add-ins/Apps it says
This app isn't supported by the version of exchange server that your
account connects to
Searching for this issue showing that the issue might be with the requirement set we use in the manifest. But, I used the same requirement set 1.1 which should support Exchange 2013 as mentioned in the docs.
What else should be done to enable Office add-on in my Exchange 2013?
Any advice/guidance would be greatly appreciated.
#user3752326, I'm glad updating to the latest Exchange 2013 CU solved your installation problem.
The reason why your add-in is not showing up in the side bar is because Exchange 2013 does not support Add-In Commands. Only Exchange 2016 or Office365 support Add-In Commands. Exchange 2013 supports legacy add-ins, which show up in the body of the message, as you have it in your screenshot.
Couple years ago I've decided to use MS Ribbon for my application.
At that time there was a choice: to use MFC Ribbon, use Windows Ribbon, or use 3rd party library.
MFC Ribbon look already was outdated (like MS Office 2007 look-and-feel).
3rd party is not an option for me.
I started to implement my app with WTL.
Right now I am using WTL 9.1 and VS 2015.
Recently I compared my app with MS Office 2016, it seems that its look became outdated.
Ribbon's XML definition starts from:
<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://schemas.microsoft.com/windows/2009/Ribbon">
<Application.Commands>
<Command Name="cmdAppMenu" Symbol="RID_RIBBON_APP_MENU" />
...
I assume that this maybe a problem (year 2009).
But I failed to find another xmlns path =(
Is it possible somehow to make ribbon in my App looks the same as in MS Office 2016?
No, this isn't possible using WTL, which is using the Windows Ribbon Framework. The Windows Ribbon Framework is API-wise something completely different than the Office ribbons. Both technologies were developed independently at Microsoft. While they share the same UI concepts, the implementation is completely different. Therefore, you won't be able to instruct your Windows Ribbon Framework based application to use the "Office style".
You will have to stick to a 3rd party library or develop a UI that looks like the Office 2016 ribbons on your own.
I've installed VB6, I've installed Sourcegear Vault 5.x and now I get this message on every VB6 startup.
And of course, I can't use the built-in source control commands.
I've tried reinstalling SourceGear Vault, to no avail. What am I missing?
How do I fix it?
General Info
You'll get this error message when VB6 loads the Source Code Control add-in but it there is no default MSSCCI provider.
MSSCCI stands for Microsoft Source Code Control Interface and it is the standard API that is used by most IDEs to connect to a version control system (VCS). It was initially developed for Visual SourceSafe, and when you installed SourceSafe it included the MSSCCI provider for IDE integration. For some modern VCSs the MSSCCI provider has to be installed separately.
You can verify what MSSCCI providers have been installed on your system by looking at the registry key HKLM\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders.
(On a 64-bit system look at HKLM\SOFTWARE\Wow6432Node\SourceCodeControlProvider\InstalledSCCProviders instead.)
Most IDEs, including VB6, only support the default provider if more than one is installed. The default provider is stored in the registry key HKLM\SOFTWARE\SourceCodeControlProvider\ProviderRegKey.
Note: a handy app called SCCSwitcher is great if you have a need to change the default MSSCCI provider.
SourceGear Vault
Since you specifically mention the problem is with SourceGear Vault, it could be that you're running into the problem described in the Vault knowledge base called VB6 and VC++ 6.0 Integration on Windows 7 that includes the following steps:
Typically, for VB6 and VC++ 6.0 integration with Vault, your client
machine needs the .NET Framework
1.1. However, this version of the Framework is not supported on Windows 7. The workaround is to make VB6 load the .NET Framework 2.0
when starting VB6.
Here are the instructions for making VB6 load the 2.0 .NET framework:
1) Make a copy of the VaultGUIClient.exe.config (in the Vault GUI
Client directory) and rename it "VB6.exe.config."
2) Copy the "VB6.exe.config" file into the same directory as the
Visual Basic executable, "VB6.exe." Edit the VB6.exe.config file,
adding runtime information after the <configuration> line:
<startup>
<supportedRuntime version="v2.0.50727"/>
<requiredRuntime version="v2.0.50727" safemode="true"/>
</startup>
so that the first part of the config file looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
<requiredRuntime version="v2.0.50727" safemode="true"/>
</startup>
<system.net>
For Visual C++ 6.0, create an "MSDEV.exe.config" file using the
instructions above and place it in the MSDEV.exe directory.
(Note: This is for VB6 and VC++ 6.0 in Visual Studio 6 only. No
special configuration is needed for VB or Visual C++ integration in VS
2005/2008/2010.)
3) You may also need to modify your registry settings for Source
Control Provider on the Vault Client machine. For 64-bit Windows 7:
3a) In the registry, under
HKEY_LOCAL_MACHINE\Software\Wow6432Node\SourceCodeControlProvider add
a string called ProviderRegKey and give it the data
SOFTWARE\SourceGear\Vault Client.
3b) In the registry, under HKEY_LOCAL_MACHINE\Software\Wow6432Node
\SourceCodeControlProvider\InstalledSCCProviders, change the key that
might list the Vault VS 2003 Compatible Client to read as SourceGear
Vault Classic Client and give it the data of SOFTWARE\SourceGear\Vault
Client
I had this same issue using 'SourceSafe 6.0' (not Vault), fixed by installing SourceSafe from the VB6 installation media (I had skipped this originally thinking the 'MSSCCI provider' would handle it).
Note: oddly the 'Source Code Control' add-in was showing 'Startup / Loaded' in VB6 IDE before SourceSafe was installed.
Ref:
w10 (64-bit)
VB6 SP6
Microsoft Visual Studio Team Foundation Server 2013&2015 MSSCCI Provider (32-bit)
(https://marketplace.visualstudio.com/items?itemName=TFSPowerToolsTeam.MicrosoftVisualStudioTeamFoundationServer20132015M)(32-bit even though is w10 64-bit)
TFS 2015 update 4.2
I am doing some research on building integrations for Microsoft Dynamics CRM Online. The integration I am building will be for Dynamics CRM Online 2013, but I am curious if the 2013 version shares an API with the 2011 version.
Does anyone know if an integration built for Dynamics CRM Online 2013 will be backwards compatible with Dynamics CRM Online 2011?
Any insight here would be appreciated.
Also, if anyone has good resources for working with these API's using Ruby that would be awesome...
Thanks!
I wrote some integration for CRM 2011 Online (C# and PHP/SOAP) and I can happily say both still work.
Any integration written with CRM4 in mind would need some modifications I believe (this may just be changing the endpoints) but 2011 and 2013 seem to work ok together.
If you are wanting to connect using a non .Net language be careful as it can be significantly more painful then creating a wrapper for the web service then talking to that from Ruby.
To connect with a non .Net language you need to use SOAP. I have put some posts here (PHP code but it should be easy enough to convert)
http://crmtroubleshoot.blogspot.com.au/2013/07/dynamics-crm-2011-php-and-soap-using.html
I currently don't have it working with Active Directory authentication though!
Everything that I've read about the API changes from 2011 to 2013 has boiled down to the removal of the CRM 4 aspx endpoint. Besides that, most of the changes to CRM are front end.
I read somewhere that a solution made in 2013 can't be exported in 2011. So I don't think will be retro-compatible.
Chapter-
Introduction to solutions
here it is from the SDK:
Version compatibility
Solutions exported from an older version can be imported into newer versions. Solutions exported from newer versions cannot be imported into older versions. This includes major and minor version differences.
Solutions exported from a Microsoft Dynamics CRM 2011 environment or a Microsoft Dynamics CRM Online organization prior to the Fall '13 Service Update can be imported into organizations using the initial release of Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online Fall '13 Service Update. However as updates are applied and include new features or metadata definitions, these new features or definitions cannot be included in a solution that is installed on an organization that is not current with the definition that the solution was exported from.
The following build error occurs when using .NET Micro Framework project, whether in emulator mode or not.
0x80131700
or
error MMP0000: 0x80131700
Solution by way of a drop-in file available on CodePlex (click here), also contains suggestions about frameworks.
Note: Ran into this problem during an electronics class, Googled the above answer, posting solution here for people to find, for archive and easy future reference.
Description
MetaDataProcessor fails with the above error during the build of .NET Micro Framework project on a computer where only .NET Framework 4.0 is installed (e.g. Visual Studio 2010 on a clean Windows XP Mode virtual machine). To workaround the issue copy the attached MetaDataProcessor.exe.config file into a directory where the .exe file is located (default %ProgramFiles%\Microsoft .NET Micro Framework\v4.1\Tools); alternatively install .NET Framework 2.0+ (3.5 SP1).
File Attachment - MetaDataProcessor.exe.config contents:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
</startup>
</configuration>