Posts filed under ‘.Net’

File not found error when you select New Webpart after installing SmartPart 1.3

Recently, I was asked to install SmartPart 1.3 on WSS 3.0. After installation, we encountered the following error when we attempt to create a new web part in the web part gallery:

File Not Found. at System.Signature._GetSignature(SignatureStruct& signature, Void* pCorSig, Int32 cCorSig, IntPtr fieldHandle, IntPtr methodHandle, IntPtr declaringTypeHandle)
at System.Signature.GetSignature(SignatureStruct& signature, Void* pCorSig, Int32 cCorSig, RuntimeFieldHandle fieldHandle, RuntimeMethodHandle methodHandle, RuntimeTypeHandle declaringTypeHandle)
at System.Signature..ctor(RuntimeMethodHandle methodHandle, RuntimeTypeHandle declaringTypeHandle)
at System.Reflection.RuntimeMethodInfo.get_Signature()
at System.Reflection.RuntimeMethodInfo.GetParameters()
at Microsoft.SharePoint.WebPartPages.SPWebPartSerializer.GetPersonalizableProperties()
at Microsoft.SharePoint.WebPartPages.SPWebPartManager.GetEffectiveWebPartType(Type webPartType, SerializationTarget serializationTarget, Boolean ignoreSupportsAttributeMarkup)
at Microsoft.SharePoint.WebPartPages.SPWebPartManager.GetEffectiveWebPartType(Type aspWebPartType, SerializationTarget serializationTarget)
at Microsoft.SharePoint.ApplicationPages.NewDwp.Page_PreRender(Object sender, EventArgs e)
at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
at System.Web.UI.Control.OnPreRender(EventArgs e)
at Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.OnPreRender(EventArgs e)
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Various sites indicated that Smartpart 1.3 requires AJAX extension 1.0. Because AJAX extension 1.0 is included in .Net Framework 3.5 SP1, I install that instead. However, this did not solve the problem. I found the solution in the comments on this post:

http://www.codeplex.com/smartpart/WorkItem/View.aspx?WorkItemId=2708

Apparently, SmartPart is binding to the older version of the System.Web.Extensions.  If I had installed an earlier version of the framework and the separate AJAX extension 1.0, it may have worked. The article does suggest a workaround.

  1. Go the the web.config of your WSS.
  2. Locate the section <runtime>, and within that <assemblyBinding>. There should be a list of <dependentAssembly> entries.
  3. Add the following entry:
<dependentAssembly>
<assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="1.0.61025.0" newVersion="3.5.0.0" />
</dependentAssembly>

What the entry does is redirect binding to the old version of System.Web.Extensions to the new version. The 3.5.0.0 version should have been installed to the GAC when you install Framework 3.5 SP1.

After this change, you will be able to create a new web part in the web part gallery again.

Advertisements

March 4, 2009 at 1:56 pm 7 comments

Error 401 when using ObjectDatasource to call a web service

Recently, I used a ObjectDataSource object to call a web service from an ASP.Net web site. Much to my surprise, I got the following error when I run it:

The request failed with HTTP status 401: Unauthorized.

In addition, the error stated the routine resulted in the following source error:

Line 111:        [return: System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
Line 112:        public string Test() {
Line 113:            object[] results = this.Invoke(“Test”, new object[0]);
Line 114:            return ((string)(results[0]));
Line 115:        }

Apparently, the error occur in line 113, when the web service is invoked. What is annoying is that the error does not appear in the security event log. Reading the IIS log file did not result in further understanding. This post did however gave me a big clue.

What appears to be happening is that the authentication credentials are not being passed to the web service. One would expect that with reflection, the ObjectDataSource would have some seamless way to pass the credentials, but there is not. You will have to create an instance of the web service proxy. A good place to do this is when the ObjectDataSource is being created. Double-click on your objectDataSource’s Object Creating event. This will create an event handler.

protected void MyObjDS_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
MyWebService.Service webProxy = new MyWebService.Service();
webProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
e.ObjectInstance = webProxy;
}

In the above example, I am passing my default credential to the web service. This occur was the ObjectDataSource is being created. Note that I am assuming that the URL of the webProxy is already set when you added the web service as a web reference. If you have different web service for each environment (dev, test, prod, etc), you can put the URL in the web.config and add an additional line to set the URL.

protected void MyObjDS_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
MyWebService.Service webProxy = new MyWebService.Service();
webService.Url = ConfigurationManager.AppSettings[“MyWebServiceURL”];
webProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
e.ObjectInstance = webProxy;
}

August 31, 2008 at 5:29 pm 6 comments

Running DotNet application under 64-bit

Recently, someone asked me to help with getting an existing Dotnet application to run on 64-bit XP. It turned out to be pretty easy, compared to the transition from 16-bit to 32-bit in the old days.

Why would you run 64-bit?

Most of the modern processor these days are 64-bit CPU, but we still live in a mostly 32-bit world. One chief reason is that 64-bit drivers are not yet available. Application compatibility is less of an issue because 64-bit windows can run 32-bit application under WOW (windows on windows). When I do see people run 64-bit OS, it is usually because they are either diehard hobbist who want the latest and greatest or they are using application that requires a large amount of memory.

DotNet under 64-bit

  • Microsoft has 32-bit and 64-bit runtime for DotNet 2.0 or above. When you install the 64-bit runtime, the 32-bit runtime is also installed.
  • Dotnet assemblies compile into MSIL (Microsoft Intermediate Language). MSIL can run in 32-bit or 64-bit mode.
  • When you compile, you have the option to compile Any CPU, x86, x64 and Itanium. Remember that DotNet does not compile into machine specific code but into MSIL. This merely set a flag to tell DotNet which environment to run in.
  • If you set the flag to any cpu, it will run in 64-bit on 64-bit machine and 32-bit on 32-bit machines.
  • If you set the flag to x86 and run it on a 64-bit machine, it will run the program under WOW in 32-bit emulation mode.
  • If you set the flag to x64 and run it on a 32-bit machine, you will get an exception.
  • The only reason you want to set the flag is dependencies. If you reference 32-bit code within your application (such as unmanaged COM code), you will need to run the application under 32-bit mode.
  • Note that DotNet 1.1 or earlier are available only in 32-bit mode. If you reference DotNet 1.1 code, you will need to run it in 32-bit mode.

 

April 23, 2008 at 8:03 am 2 comments

Organizing NUnit Test in a .Net or MonoDevelop Solution

When I first use Nunit, I was confused on how to set up Nunit test inside a solution. I can think of several alternatives:

  1. Have Nunit test be in the same project / Assembly.
  2. Same as 1, but use a compiler flag like #ifdebug to filter out the Nunit code during production.
  3. Create a single test project where unit test for all solutions resides. So there is a single “Unit Test” project solution where all of the unit test are stored.
  4. For each project in the solution being tested, create a corresponding test project. So if you have a “Calculation” project, you would have a corresponding “Calculation Test” project that holds all of the unit test for Calculation Project.

Personally, I do not like option 1 because it deploys Nunit code into production. I do not like option 2 because preprocessor macros are error prone. In addition, if you are only testing when the debug flag is true, are you really testing the code?

I prefer option 4 over option 3 because it gives me the flexibility to organize the test and also promote isolation between different tests. If you lump all of the test under the same project, it may be difficult to figure out which test is from which project.

For example, if we want to do a Calculator application, you’ll end up with the following solution structure:

Calculator — Solution for the calculator application

CalculatorApplication — Startup project. Contains the main routine.

CalculatorClass — this is the class code for the calculator.

CalculatorClassTest — this is the unit test for the CalculatorClass.

For each project will have a corresponding unit test project. The unit test project will reference the assembly of the project being tested. The CalculatorApplication just enough code to call the other classes. It is not tested. It may be a pain to setup at first, but it is the most organized and flexible way to organized your unit test.

April 14, 2008 at 9:18 pm Leave a comment

Error Code: 66A when installing the Visual Studio 2005 SP1 for Windows Vista

I installed Visual Studio 2005 on Vista recently and got an error when attempting to open a new project. Not to worry, I rememeber a friend mentioning that I need to install Visual Studio 2005 SP1. I quickly downloaded Visual Studio 2005 SP1 for Windows Vista and install it, but it complain that it can’t find the Visual Studio 2005 software. Windows update also attempt to install Windows Studio 2005 SP1 for Windows Vista during the OS updates, which I assume to be the same file I just downloaded. It however failed to install, the updater list “Error Code: 66A”.

It turns out that there are actually two Visual Studio 2005 SP1. There’s Visual Studio 2005 SP1, which you have to download and install first. Afterwards, you can you Windows updater to install Visual Studio 2005 SP1 for Windows Vista. The SP1 for Windows Vista will not install until you first install SP1. Once I installed Visual Studio 2005 SP1 first, the error code went away when I installed Visual Studio 2005 SP1 for Windows Vista.

To further the confusion, Visual Studio 2005 SP1 has a separate updater for Visual Studio 2005 Express and Visual Studio 2005 Team Suite. Use the express installer for Visual Studio 2005 express, and the team suite installer for everything else. 

August 30, 2007 at 7:50 am Leave a comment

Creating a XML Document from scratch without using a file in C#

One thing that’s annoying is that majority of the XML example assumes that you are loading an XML document from a file, so here’s a simple code example for generating it entirely in memory.

// Create the xml document containe
XmlDocument doc = new XmlDocument();
// Create the XML Declaration, and append it to XML document
XmlDeclaration dec = doc.CreateXmlDeclaration("1.0", null, null);
doc.AppendChild(dec);
// Create the root element
XmlElement root = doc.CreateElement("Library");
doc.AppendChild(root);

// Create Books
// Note that to set the text inside the element,
// you use .InnerText instead of .Value (which will throw an exception).
// You use SetAttribute to set attribute
XmlElement book = doc.CreateElement("Book");
book.SetAttribute("BookType", "Hardcover");
XmlElement title = doc.CreateElement("Title");
title.InnerText = "Door Number Three";
XmlElement author = doc.CreateElement("Author");
author.InnerText = "O'Leary, Patrick";
book.AppendChild(title);
book.AppendChild(author);
root.AppendChild(book);

book = doc.CreateElement("Book");
book.SetAttribute("BookType", "Paperback");
title = doc.CreateElement("Title");
title.InnerText = "Lord of Light";
author = doc.CreateElement("Author");
author.InnerText = "Zelanzy, Roger";
book.AppendChild(title);
book.AppendChild(author);
root.AppendChild(book);

string xmlOutput = doc.OuterXml;

The same code but using an XMLWriter to a memory stream.


XmlWriterSettings wSettings = new XmlWriterSettings();
wSettings.Indent = true;
MemoryStream ms = new MemoryStream();
XmlWriter xw = XmlWriter.Create(ms, wSettings);
// Write Declaration
xw.WriteStartDocument();

// Write the root node
xw.WriteStartElement("Library");

// Write the books and the book elements
xw.WriteStartElement("Book");
xw.WriteStartAttribute("BookType");
xw.WriteString("Hardback");
xw.WriteEndAttribute();

xw.WriteStartElement("Title");
xw.WriteString("Door Number Three");
xw.WriteEndElement();
xw.WriteStartElement("Author");
xw.WriteString("O'Leary, Patrick");
xw.WriteEndElement();

xw.WriteEndElement();

// Write another book
xw.WriteStartElement("Book");
xw.WriteStartAttribute("BookType");
xw.WriteString("Paperback");
xw.WriteEndAttribute();

xw.WriteStartElement("Title");
xw.WriteString("Lord of Light");
xw.WriteEndElement();
xw.WriteStartElement("Author");
xw.WriteString("Zelanzy, Roger");
xw.WriteEndElement();

xw.WriteEndElement();

// Close the document
xw.WriteEndDocument();

// Flush the write
xw.Flush();

Byte[] buffer = new Byte[ms.Length];
buffer = ms.ToArray();
string xmlOutput = System.Text.Encoding.UTF8.GetString(buffer);

April 4, 2007 at 2:15 pm 57 comments

Memory Leak when disposing of .Net child Winform with mainmenu

I had an application recently that has a child window with a mainmenu. I begin noticing that memory weren't being released even when I dispose of the child form. I decided to do an experiment by creating a simple app that creates 10 child window and closes then each time a button is press. The form are disposed of immediately after they are closed. I then examine the run under the CLRProfiler.

What seems to be happening is that the event handler for the form prevent the child form from being garbage collected. However, this is technically not a leak, since after about 250 form objects are on the heap, some of the child forms are cleaned up. It's just that the CLR seems to be holding on to the child form longer than normal due to the menuitem event handler.

I tried this under VS.Net 2005 and notice that the problem does not occur, so it only affects VS.Net 2003. It's also possible that Microsoft may have a patch for this problem for VS.Net 2003, but I did not see it mentioned when I search MSDN.

June 18, 2006 at 5:23 pm Leave a comment

Older Posts


Calendar

September 2017
M T W T F S S
« Jun    
 123
45678910
11121314151617
18192021222324
252627282930  

Posts by Month

Posts by Category