At our company, we were provided with a customised dll 'DGS.Common' which handles trace functionality (using System.diagnostics) and built on .net framework 2.0

->Earlier when we were running our applications using Biztalk 2006R2 and .net framework 2, tracing worked fine.
->  We had the trace connection and diagnostic switch values set up in the Biztalk config file(BTSNTSVC.exe.config) file

Later when we migrated our application to Biztalk 2013 and .net framework 4.5, while rest of the application
was upgraded to .net 4.5, DGs.Common.dll was still a .net 2 dll (installed 32 bit GAC while the other dlls are in 64 bit GAC)

Now  the application is unable to pick up the trace settings(connection and switch values) from BTSNTSVC.exe.config or BTSNTSVC64.exe.config file
But if we have these settings in machine.config file(64 bit), it is picking up from there.

Not sure what we are missing here and if there is a way to make it pick from biztalk config file instead of machine.config file

Appreciate any insight and inputs!ThankU!!

It could be because of the different assembly location in .NET for and for .NET 4.5. for v2.0 C:\Windows\Microsoft.NET\assembly\GAC_MSIL and v4 or later versions uses %\Windows\Microsoft.Net\assembly\GAC_MSIL.

I think since there is a conflict in assembly location between versions the config values are not able to load correctly. Hence the configurations from machine.config are fetched.

 Is there a way to make it read from Biztalk config file instead of Machine.config file? From my application perspective, we need to have these values in Biztalk config file.

Rebuild your tracing component in the latest version of Visual studio to create .NET 4.5 assembly and GAC this .NET 4.5 built assembly.

Answering my own question afte a long time.

The root element under which I placed <system.diagnostics> element was incorrect.

Once I moved it to just one level below <configuration> element it, the issue is resolved.

• Marked as answer by Annee797 13 hours 22 minutes ago

Answering my own question afte a long time.

The root element under which I placed <system.diagnostics> element was incorrect.

Once I moved it to just one level below <configuration> element it, the issue is resolved.

• Marked as answer by Annee797 Monday, May 04, 2015 5:41 PM

Answering my own question afte a long time.

The root element under which I placed <system.diagnostics> element was incorrect.

Once I moved it to just one level below <configuration> element it, the issue is resolved.

• Marked as answer by Annee797 Monday, May 04, 2015 5:41 PM

Answering my own question afte a long time.

The root element under which I placed <system.diagnostics> element was incorrect.

Once I moved it to just one level below <configuration> element it, the issue is resolved.

• Marked as answer by Annee797 Monday, May 04, 2015 5:41 PM

Answering my own question afte a long time.

The root element under which I placed <system.diagnostics> element was incorrect.

Once I moved it to just one level below <configuration> element it, the issue is resolved.

• Marked as answer by Annee797 Monday, May 04, 2015 5:41 PM