.NET Questions and Solutions

Symptoms
When you call the MethodInfo.Invoke method, you may receive the following error message:

An unhandled exception of type ‘System.Reflection.TargetInvocationException’ occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an invocation.
You may also receive an additional error message that is similar to the following error message:

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.IO.FileLoadException: ‘ClassLibrary1′ is not a valid file.
File name: “ClassLibrary1″
at ClassLibrary2.Class1.GetString()
Resolution
You receive the System.Reflection.TargetInvocationException error because the common language runtime calls the MethodInfo.Invoke method by using reflection.
When you load an assembly by using the Assembly.LoadFrom method, the common language runtime places the loaded assembly in the LoadFrom context of your application. Any probes for the dependencies of the assembly first probe the current application directory. If this probe fails, the common language runtime then probes the LoadFrom context of your application.
You may load an assembly that has a simply-named dependency that has the same file name as a file in the current application directory. When you try to invoke a method in the loaded assembly by using the MethodInfo.Invoke method, and the invoked method uses the dependency, the common language runtime first probes the current directory path. When the common language runtime finds a file that has the same file name as the dependency, the probe stops. However, if this file does not have the same assembly identity as the dependency, the assembly bind fails, and the common language runtime generates a System.IO.FileLoadException error that is passed to the System.Reflection.TargetInvocationException error. Therefore, you may notice the behavior that is mentioned in the “Symptoms” section.

Symptoms
When you migrate a Microsoft Transaction Server (MTS) application to COM+, and you do not call the SetComplete or SetAbort method, an Access Violation may occur, and the application may fail (crash). This problem occurs in COM+ (Windows 2000 Service Pack 1) and not in MTS.
Resolution
This problem occurs when non-root transactional objects release the object reference to their parent object and do not call SetComplete or SetAbort explicitly at the end of the method.
This problem is caused by a difference in the activation and deactivation mechanisms between COM+ and MTS. In COM+, if the child object does not set the done bit to true (if it does not call the IObjectControl::SetComplete or the IObjectControl::SetAbort method, does not call the IContextState:setCompletion method, or does not use Auto-Completion), the COM+ interception layer deactivates the parent object before the child object. In fact, you do not need to set the done bit, even if it is preferred in most situations.

Symptoms
Consider the following scenario: You create a recurring meeting request in Microsoft Office Outlook 2003.You modify any field in the instances of the recurring meeting request to create exception meeting requests.Recipients use a Collaboration Data Objects (CDO) 1.21 application to accept the exception meeting request first. Then, they use the CDO 1.21 application to accept the master meeting request. In this scenario, the exception meeting requests are deleted from the calendar in Outlook 2003.
Resolution
When the Respond method is used to accept the master meeting request, the CDO 1.21 application internally uses the GetAssociatedAppointment method. This internal call to the GetAssociatedAppointment method merges the exceptions into a temporary associated appointment and then deletes the exceptions. However, the GetAssociatedAppointment method does not save the associated appointment. Because the associated appointment is not saved, the merged exceptions are lost when the master meeting request is accepted.

Symptoms
Consider the following scenario. In the Microsoft .NET Framework 2.0, you create an instance of the EventLogPermission class that has the EventLogPermissionAccess.Write access level. You call the EventLogPermission.PermitOnly method to restrict code access. Then you call the EventLog.WriteEntry method to write an entry to the event log. In this scenario,you receive a security exception error message that resembles the following:

Unhandled Exception: System.Security.SecurityException: Request for the permission of type ‘System.Diagnostics.EventLogPermission, …’ failed.
Resolution
To work around this issue, you must request the EventLogPermissionAccess.Administer access level before you call the EventLogPermission.PermitOnly method. After you specify this access level, you can call the EventLog.WriteEntry method and write an entry to the event log. The following code example demonstrates how to write an entry to the event log by using this workaround.
Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements.

using System;using System.Diagnostics;public class TestCase{ public static void Main() { EventLogPermission eventLogPermission = new EventLogPermission(EventLogPermissionAccess.Administer, “.”); eventLogPermission.PermitOnly(); EventLog.WriteEntry(“Source”, “Message”); }}

Symptoms
The Queue class is a Microsoft .NET Framework Class Library class. It represents a first-in, first-out collection of objects. However, if you use the Queue.Clone method to clone a queue, and if the call to the Queue.Dequeue method is made before the call to Queue.Clone method is made, the data is lost.
Resolution
A bounded buffer is used to implement the Queue class. The Clone method uses the beginning of the buffer, instead of the head pointer, as the starting point. When the Dequeue method is called, the first element is removed. However, the beginning of the buffer remains the same. Therefore, the first element appears as an empty element and the last element is lost in the cloning process.

Symptoms
You have a Web Service that has a Web Service method that returns an instance of a custom class. The class that is returned by the Web Service method implements the IXmlSerializable interface. If you use this Web Service in an application, you may receive the following error message when you build the application:

Cannot implicitly convert type ‘System.Data.DataSet’ to ‘ClassLibrary.ClassName’
Resolution
When you add a Web reference to a Web Service, Microsoft Visual Studio .NET incorrectly uses System.Data.DataSet instead of the class that implements the IXmlSerializable interface. Therefore, the Web Service method in the proxy class returns System.Data.DataSet instead of the custom class that implements the IXmlSerializable interface. Therefore, you receive the error message when you consume the Web Service method in your Web application.