It ended up working with a RelativeSource binding like this:

<ControlTemplate x:Key="CustomTabControlTemplate" TargetType="{x:Type TabControl}">

        ...

        <ItemsControl  Grid.Column="0" Grid.Row="0" Grid.ColumnSpan="2" >

            <ItemsControl.ItemsSource>

                <Binding Mode="OneWay" Path="Items">

                    <Binding.RelativeSource>

                        <RelativeSource

                        Mode="TemplatedParent"

                        />

                    </Binding.RelativeSource>

                </Binding>

            </ItemsControl.ItemsSource>

        </ItemsControl>

I was intrigued that using the more usual TemplateBinding did not work (you get a compile time error):

<ItemsControl  ItemsSource="{TemplateBinding Items}" Grid.Column="0" Grid.Row="0" Grid.ColumnSpan="2" />

 From the TemplateBinding docs, one can get the (wrong) impression that it should actually work. It says:

A TemplateBinding is an optimized form of a Binding for template scenarios, analogous to a Binding constructed with {Binding RelativeSource={RelativeSource TemplatedParent} Mode=OneWay}.  

The word "analogous" is misleading. At a search, it was clear that there are significant differences under the hood between Binding and TemplateBinding. Some of them are described here, however, none of them seemed to apply, which is why I tried to look again more carefully at the docs. And there's the explanation right on the TemplateBinding docs page: unlike a Binding, a TemplateBinding can only bind a DependencyProperty to another DependencyPropery (IMHO, the wording of "targetProperty" in the docs below is confusing/wrong from a WPF binding terminology perspective, because the property on the type being templated is actually the source, the target being propertyName !):

propertyName	DependencyProperty..::.Name of the property being set in the setter syntax.
targetProperty	A dependency property that exists on the type being templated, specified by its DependencyProperty..::.Name. - or - A "dotted-down" property name that is defined by a different type than the target type being templated. This is actually a PropertyPath. See PropertyPath XAML Syntax.

 

But Items in an ItemsControl is not a DependencyProperty (ItemsSource is !) which is why only a RelativeSource Binding works in this case.

With the advent of .NET, one of the key features that has enabled developer productivity is without doubt code-level interoperability between the native and managed world. This allows developers to bring a large variety of code components under the same application hood:

• .NET assemblies
• .NET Winforms controls
• WPF components (via WPF/Winforms interoperability)
• native Dlls
• MFC
• COM / ActiveX
• and so on

To accomplish interoperability at code level, several mechanisms to go from native to managed and the other way round are available:

• P/Invoke: allows direct calls from .NET into native Dlls via DllImports. Marshalling of data types can be controlled by DllImport attributes. A sort of a native-to -managed counterpart of this is the Marshal::GetFunctionPointerForDelegate() function in System.Runtime.InteropServices, which allows converting a managed delegate into a function pointer that can be called from unmanaged code. For example:

namespace ClassLibrary1

{

    public class Class1

    {

        [DllImport("NativeDll.dll", EntryPoint = "#1")]

        static extern UInt32 MyFunction(UInt32 a);

 

        public int Calculate(int a, int b)

        {

                     int r = (int)MyFunction(200);

• COM Interop: allows bi-directional interop via COM. Marshalling to/from .NET is taken care of transparentty by the CLR using wrappers, so this can be expensive in terms of performance.

Usually you would use Interop Assemblies (usually generated with tlbimp ) to call into COM from .NET. For the other way round, you can register a .NET assembly for COM Interop by using regasm or use the integrated Visual Studio support (Register for COM interop).

• CLR hosting API: allosw native application to host and fine-grain control the CLR and call into .NET components. However, having to handle all CLR hosting aspects manually is a significant overhead.
• C++/CLI: also known as It Just Works(IJW),  achieves interoperability at compiler level (C++, /clr compiler flag) by mixing native and managed code in a transparent way. It provides a lot of control on where the native/managed transition occurs and also provide high performance (basically, by transparently handling P/Invoke calls)

//Calling into managed code from C++ native MFC app:

using namespace ClassLibrary1;

…

BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)

END_MESSAGE_MAP()

 

void CallManagedFromMFC()

{

                                                Class1^ c = gcnew Class1();

                                                int result = c->Calculate(3,4);

                                                CString str = String::Format("Result: {0}", result);

                                                AfxMessageBox(str);

}

 

Clearly, things don't always work seamlessly together when integrating native and managed code and one major aspect in a mixed-mode scenario is error and exception handling - simply because there are significant differences in the exception generation and handling mechanisms in different types of components, especially when crossing the native/managed border.

One important thing to know is that the Common Language Runtime represents its managed exceptions as native SEH(Structured Exception Handling) exceptions and installs its own SEH filter for that - but the managed exception information is not carried in the SEH exception but rather managed internally in the CLR. This allows the CLR to fit quite well in a mixed application which is using also SEH.

While you can get CLR exceptions as native SEH in a native UnhandledExceptionFilter(), you will not be able to access managed exception information - simply because only the CLR itself can access that information.If you are chaining a SEH  UnhandledExceptionFilter() in your mixed application - which you should only do for good reason - there are two thighs to take into consideration:

• propelry chain your filter as a "good Win32 citizen" and call the previously set filter before doing your processing
• it is imperative not to interfere with the CLR SEH exceptions and always return EXCEPTION_CONTINUE_SEARCH for such exceptions - as for any exceptions you are not handling yourself: otherwise you can easily put the CLR in an undefined state.

Here's a code snippet, again from a MFC Application which sets a trivial UnhandledExceptionFilter that should behave well with the CLR:

#define CLR_EXCEPTION_CODE 0xE0434F4D

LPTOP_LEVEL_EXCEPTION_FILTER topLevelEF;

 

LONG WINAPI UEFHandler(struct _EXCEPTION_POINTERS *ExceptionInfo)

{

                        // call previous handler first

                        (*topLevelEF)(ExceptionInfo);

                        _EXCEPTION_RECORD *ExceptionRecord = ExceptionInfo->ExceptionRecord;

 

                        if (ExceptionRecord->ExceptionCode==CLR_EXCEPTION_CODE)

                        {

                                                // CLR Exception in native handler

                                                return EXCEPTION_CONTINUE_SEARCH;

                        }

                       

                        return EXCEPTION_CONTINUE_SEARCH;

}

 

 

 

BOOL CMfcTestApp::InitInstance()

{

                        topLevelEF= SetUnhandledExceptionFilter(UEFHandler);

As said, you will not be able to get managed exception information in a native handler - you must use try/catch in C++/CLI - that is, in a managed context - if you really need that information.

Generally speaking, it is easier to deal with native errors/exceptions in managed code that the other way round, the main reason being that native code is unaware of managed concepts like managed exceptions, managed threads, application domains and so on. Let's see some common scenarios:

1. P/Invoke is fairly straightforward: it is common practice to wrap your P/Invoke call in a try/catch block to get the exceptions generated by the call. You will get both exceptions generated by the P/Invoke service itself (like not finding the Dll or the entry point) and exceptions generated by the call itself. For Win32 functions, you can also retrieve the Win32 error code. See here for more details.
2. In COM Interop, the runtime is converting COM HRESULT values to managed exceptions and the other way round: there is a layer of separation at the COM interfaces level. See here for further reading: https://msdn.microsoft.com/en-us/library/awy7adbx.aspx
3. Ther CLR Hosting APIs allow extensive control of how CLR faults and exceptions are handled - but this is a fairly complex topic and most people prefer the C++/CLI approach
4. C++/CLI provides a seamless exception handling approach for the programmer: you can catch both managed and native exceptions in /clr compiled code.  

• because you are running on a thread that has not been created by the CLR, the CLR unhandled exception mechanism may not be triggered in some situations - actually, it will only be triggered if the native thread is calling into .NET outside of any SEH handler protection
• one side effect of this that I have encountered is that you will not get a AppDomain.UnhandledException Event in your application.This actually makes sense, as AppDomain is a purely managed concept.

If you rely on AppDomain.UnhandledException to log errors in your managed code, this will not work when running managed code on a native thread. If you absolutely need to get detailed managed exception information in a central handler - which is NOT something recommended (catch-all is not a good practice) - you will have to try/catch managed exception on a native frame that will get them. From a troubleshooting point of view, it should be better to just let your app crash and thus get exception info (dump) post-mortem rather than unwinding the stack in a catch-all handler. For reference, however, here's how you can get managed exceptions by overriding OnCmdMsg()  in a MFC app:

BOOL CMfcTestApp::OnCmdMsg( 

   UINT nID, 

   int nCode, 

   void* pExtra, 

   AFX_CMDHANDLERINFO* pHandlerInfo  

) 

{ 

    try 

    { 

        return CWinApp::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo); 

    } 

    catch (System::Exception ^ex) 

    { 

                                                System::Windows::Forms::MessageBox::Show("Whoops! Maneged exception.");

        return 0; 

    } 

} 

 

• Speaking of AppDomains: since this is a pure managed concept, the question arises: in which AppDomain will a native thread calling into .NET be running ? The CLR must pick an AppDomain and it will the AppDomain the thread was the last time it called into managed code - usually the default AppDomain. You can have some control over the AppDomain by using Delegates and Marshal::GetFunctionPointerForDelegate() , as Delegates keep a reference to their AppDomain.

1. Publishing ClickOnce applications for external users (Internet)
2. Publishing for a restricted group of internal users (Intranet)

An excellent document on the subject is here: https://msdn.microsoft.com/en-us/library/aa730868(VS.80).aspx 

For the first scenario, it is generally clear that a trusted certificate signed by a Certificate Authority is needed in order to ensure that the application publisher is trusted. Additionally, Trusted Application Deployment (TAD) also requires a CA signed certificate: https://msdn.microsoft.com/en-us/library/01daf08f.aspx

The second type of scenario is often asked about for internal deployments in "trusted" smaller environments - like a developer team: the overhead of a CA certificate is considered unnecessary. Because ClickOnce works with self-signed certificates (like Personal Information Exchange .pfx ), this can be used as alternative. Following things need to be considered:

1. By default, Visual Studio will automatically generate test certificates for you and add the PFX file to your project. If several developers need to be able to publish application updates, the they must use the same certificate (otherwise the update will fail)
2. So it should be OK to check the PFX with your project in source control and have all developers use it - Visual Studio will automatically import the PFX in the local certificate store of each machine where the project is published (ClickOnce manifest signing always works by first importing the PFX certificate in the local Certificate Store)
3. However, VisualStudio test certificates have a limited validity: they expire after one year. It is possible to extend them, but it's not worth the risk of forgetting when it expires (which will cause application updates to fail). A better options is available: creating and using a self-signed certificate with the .NET 2.0 makecert.exe Tool:

https://msdn.microsoft.com/en-us/library/e78byta0(VS.80).aspx

The tool allows you to create a certificate with the desired expiration date and exporting this to a PFX file which can be used just like a Visual Studio test certificate. The private key can be password protected.

As a side note in this scenario, you should periodically make sure your usage of self-signed certificates is really appropriate from a security point of view.

 I will try to shed some light on this:

• First of all, there is currently no official Microsoft docs that describes such details. There is a reason for that: not only is manually touching the TFS (as well as Reporting Services and Sharepoint) databases, including permissions and roles, not recommended, but it can easily put you in an unsupported state (if you raise a support incident with MS). When TFS is installed, the configured database settings should work with all supported TFS operation and migration scenarios without requiring any manual touch of the databases (apart from backup/restores).

• However, in troubleshooting scenarios it might be useful to check some basic things in the TFS-related databases:
• Typically, TFSService is in the dbcreator and securityadmin Server Roles. If it is not, this is not necessarily an issue, but you might want to check if someone has done some manual configuration on SQL settings
• TFSService should have User Mappings to the following databases (names of the Sahrepoint DBs might vary ): TFSActivityTracking, TFSBuild,TFSIntegration, TFSVersionControl, TFSWorkitemTracking, TFSWorkitemTrackingAttachements, TFSWarehouse STS_Config_TFS STS_Content_TFS
• TFSService should be in the TFSEXECROLE for all TFS-related databases. This is owned by dbo, which in turn grants db_owner to the TFS Databases.
• TFSReports should have a User Mapping on TFSWarehouse

This list is not exhaustive, but rather something you should expect to see on a properly installed TFS (2005 and 2008)

• You might also check this blog post from the TFS Setup/Install Team: https://blogs.msdn.com/tfssetup/archive/2009/08/05/tfs-2008-permission-requirements-for-team-foundation-server-service-account.aspx

Please note the explicit reccomendation not to use these settings on a permanent basis or when servicing TFS!

The morale: apart from obvious issues, you should stay away of manually configuring TFS databases manually. For troubleshooting, try using TFS Best Practices Analyzer (BPA, https://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx) first, it should detect most database/SQL logins configuration issues.

In spite of being a rather old technology, Visual Basic 6 code is still among us - to a suprisingly large extent. Some usual places where you find VB6 these days:

·         VB6 desktop applications and custom controls

·         VB6 ActiveX controls hosted on Web sites or in desktop applications (including .NET applications)

·         VB6 ActiveX controls in Office VBA aplications

The support for VB6 IDE has ended on 8. April 2008, but Microsoft is committed to further supporting the so-called Visual Basic 6.0 Runtime Extended Files, which include most of the VB6 Controls originally shipped with the VB6 IDE, in order to allow legacy VB6 code to run even on newer operating systems. The details are here:

https://msdn.microsoft.com/en-us/vbrun/ms788708.aspx

Kill-bits

Recently, we have seen an almost unprecedented effort in strengthening security on MS operating systems: as part of this effort, several vulnerabilities in the original releases in many VB6 ActiveX Controls have been discovered. The primary solution to address these issues was publishing several Security Bulletins and Advisories containing Kill-Bits for the vulnerable ActiveX controls. What a Kill-Bit is and how it works is explained here:

https://support.microsoft.com/default.aspx?scid=kb;EN-US;240797

In short:

·         The "Compatibility Flags" register value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control is set to a bit mask that prevents the ActiveX control to be instantiated

·         Optionally, an AlternateCLSID for a new version of the control in which the vulnerability has been fixed is provided.  This allows the transparent instantiation of the new control via the old CLSID  (the system is doing this redirection for you).  There are some catches to this with licensing issues - as described below.

An important note: Kill-Bits do not only affect  Internet Explorer - I have encountered this misunderstanding quite often. What applications respect the Kill-Bits - as well as a wealth of other  infos on Kill-Bits - you can read here:

https://blogs.technet.com/srd/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-1-of-3.aspx

https://blogs.technet.com/srd/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-2-of-3.aspx

https://blogs.technet.com/srd/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-3-of-3.aspx

What applications respect the Kill-Bit?

The Kill-Bit is respected in Internet Explorer (all zones) and also in Microsoft Office scenarios where objects are embedded within documents. The Kill-Bit should also be effective by default in any other application or platform that hosts the IE browser’s rendering engine (MSHTML).

In addition to the Kill-Bit mechanism per se, upgrading Kill-Bit-ed controls to new, unblocked versions using AlternateCLSIDs can also lead to licensing issues in applications that would otherwise ignore the Kill-Bit (as described  below).

How can I be affected

If you are – maybe without even realizing - using VB6 components in applications on your computer/server, sooner or later you will probably come across Kill-Bits - either because you install one of the MS Security Bulletins containing Kill-Bits or because this is automatically installed by Windows Update (some of the vulnerabilities are rated critical, so installing the patches do by far more good than bad !)

Kill-Bits Security bulletins are cumulative, the most recent ist:

https://www.microsoft.com/technet/security/bulletin/ms09-032.mspx

What kill bits does this Cumulative Security Update of ActiveX Kill Bits contain?
This Cumulative Security Update of ActiveX Kill Bits contains all kill bits previously released in MS08-023, Security Update of ActiveX Kill Bits; MS08-032, Cumulative Security Update of ActiveX Kill Bits; and advisories entitled Update Rollup for ActiveX Kill Bits, Microsoft Security Advisory 953839, Microsoft Security Advisory 956391, Microsoft Security Advisory 960715, and Microsoft Security Advisory 969898.

So what do you do if one of the Kill-Bit Security Updates is breaking your application, web site or Office VBA code  that uses VB6 Controls ? First of all, make sure the control that has stopped working is indeed part of the supported VB6 Runtime:  you can look it up in the Cumulative Rollup for the VB6 SP6 Runtime Extended Files:

https://support.microsoft.com/kb/957924

This contains new versions of VB6 Controls that replace the old, vulnerable ones by redirecting them to AlternateCLSIDs so that the Kill-Bits are no longer blocking them.  You need to get these updated versions o VB6 controls onto the affected computers.

At this point, there is one important mention to be made: you cannot simply install this patch on an affected machine - it will only install on a machine with a VB6 IDE license. The reason is simple: VB6 Controls are licensed controls that can only be redistributed by packing them in your VB6 application setup.

So how do you get the new VB6 Controls on the machines where KillBits have disabled your VB6 code functionality ? The answer is: it depends on the application.

1.       A "pure" VB6 application or control running in a Kill Bit-unaware application can still run with killbit-ed VB6 Controls. However, it is still a good idea to install KB 957924 on the development machine with VB6 IDE, recompile your VB6 code there and the re-deploy your application  with the new VB6 Controls.

The reason is that, if you don't recompile your code with the new controls from KB 957924 and later deploy these controls as part of a Kill Bit-aware applications that requires them, you  will run into licensing issues on the target machines when running the VB6 app. This is because the runtime license for VB6 controls that is embedded in your old application or custom control is not valid for the new version of the control, which has a different CLSID. Therefore, when you run the app on the target machine, the runtime license will be invalid and - if no design-time license is present, which should only be the case on a machine with VB6 IDE - the instantiation of the control will fail and you will most probably see something like this:

The morale is: simply recompile your VB6 code with KB 957924 controls, redeploy and save yourself the hassle.

2.       If you are hosting VB6 controls on a web site, you will need to deploy the KB 957924 controls and, additionally, you will run into the LPK (license file for hosting in IE) issue as described here:

https://blogs.msdn.com/askie/archive/2009/02/20/certain-vb-controls-no-longer-display-on-web-pages-after-installing-kb960715.aspx

Currently, the only workaround is to call Microsoft Support and get an updated LPK file for the controls. As the above blog post suggests, some work is currently done on the Internet Explorer client side to enable instantiation with the old LPK file and alleviate the issue.

3.       If you have issues with Office VBA components (which are Kill-Bit aware !), read this excellent blog post from the Visual Studio Office Dev Team here:

https://blogs.msdn.com/vsod/archive/2009/06/05/visual-basic-6-controls-stop-working-after-security-advisory-960715.aspx

The preferred way to deal with this is to rebuild your Office VBA component on a VB6 machine with the updated controls.

Other resources:

·         Stay updated on Security Updates  and bulletins on the Microsoft Security Research & Defense blog: https://blogs.technet.com/srd/