Problem upgrading ComponentArt

Problem:

After upgrading a component I began getting the following error:

Could not load file or assembly 'ComponentArt.Web.UI, Version=2006.2.1507.2, Culture=neutral, PublicKeyToken=9bc9f846553156bb' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Solution:

The problem was with the manifest reporting I needed version ...1507.2 of the file when in fact I had version Version ...1507.3 of the file in the bin directory. The ...1507.3 version of the file was both in the Main projects references correctly and in the dependent project references correctly. Nowhere did it show as the old version--though the day before I had the previous version in stalled and I overwrote the dll with the newer one. I assumed something was cached somewhere.

I used advice from the following two urls to help:

http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx
http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx

I did the following the following to solve my problem:

1. I updated the registry key [HKLM\Software\Microsoft\Fusion\LogFailures] (DWORD) to 1 -- This required me setting permissions on the Fusion key so that I could even see the LogFailures value (which was already there and set to 1).
2. I ran my application in debug mode and got a much more helpful error message: Which pointed to a dependency project even though the error was reported in the main project.
   
3. Though the dependent project appeared to have the dll registered correctly, I had to remove the 'obj' directory from it and from the main project and recompile to get rid of all of the cached pointers to the old dll.

This fixed my problem.

ComponentArt upgrade issue

Problem:

After upgrading the ComponentArt.Web.UI.dll from 2006.1.1283 to 2006.2.1507.2 I was getting the following error:

... 2006_2_1507/A573G988.js not found

My first thought was that I needed to copy a client side library to this location. So I searched and searched and couldn't find a 2006_2_1507 client library. Nor could I find the error in the ComponentArt forum.

Solution:

In the aspx page, where I create my ComponentArt control, there was an attribute on the control called ClientScriptLocation which we had set to the location of our client library for the previous version of ComponentArt.

The new version does not need a client library, but still has the functionality. So I removed the value from the ClientScriptLocation attribute and all is well. The component will generate the required client script as needed.

Using STA COM components in a HTTPHandler

Problem:

So I had this good idea that I would use an HTTPHandler to for our multi file upload project. I have a Java Applet that allows the user to drag and drop or select from a dialog multiple files to upload.

Before I tried to integrate any of this into the main project, I created a proof-of-concept to test with and had no problem with it.

I have a HTTPHandler that implements the System.Web.SessionState.IRequiresSessionState interface which insures I get the session and all was well in my proof-of-concept project. When I moved it, I had to add the functionality that I thought would work without any modifications, but I could not have been more wrong.

First of all, the applet has some sort of java based browser that renders html. This browser apparently starts a new session with the web server so I had to post my session variables in URL parameters (not too big a deal). Then, I tried to implement some code that worked just fine on our single file upload aspx page and suddenly I was in trouble.

The code used COM components from the old ASP days and worked just fine on a WebForm with the ASPCompat page directive set to "true". But HTTPHandlers have no page directives and do not support ASPCompat, so now what?


Solution:

Well after a lot of searching I came across the following article that helped me out: http://www.epocalipse.com/blog/2006/03/04/aspnet-web-services-and-sta-com-objects/

Basically I implemented the System.Web.IHttpAsyncHandler and inherited the System.Web.UI.Page. Then I added the following functions:

Public Function BeginProcessRequest(ByVal context As System.Web.HttpContext, ByVal cb As System.AsyncCallback, ByVal extraData As Object) As System.IAsyncResult Implements System.Web.IHttpAsyncHandler.BeginProcessRequest
Return AspCompatBeginProcessRequest(context, cb, extraData)
End Function

Public Sub EndProcessRequest(ByVal result As System.IAsyncResult) Implements System.Web.IHttpAsyncHandler.EndProcessRequest
AspCompatEndProcessRequest(result)
End Sub

Private Sub FileUpload_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
'The code that used to be in ProcessRequest goes here
End Sub

Now I know what you are thinking. Hey what's up? Why use a HTTPHandler if you are just going to inherit System.Web.UI.Page anyway? Why not just use a webform?

Well, the problem is that I needed a quick fix so that I could move on. This allows me to run STA COM components in my HTTPHandler and hey, I still have a little more control than if this was a webform. And I am able to auto generate a config file used by my Java applet, that is hard coded in the applet (the applet uses a file called thinupload.properties and I wanted to auto generate that file, this allows me to handle .properties files and create the config file on the fly).

Object moved to here

Problem:

Yesterday I spent about half of the day working on a problem where I was using Thin Upload Pro to upload multiple files to our web server. Everything worked fine in the development environment but when I moved it to test, I received the message "Object moved to here" in the applet.

I found several articles on this, but they seemed to all refer to using the 1.1 .NET framework. This project was using the 2.0 framework.

The applet was showing the page just fine on first load. But when I would drag files in to the applet to upload them (which posted back to the same page) I would get the error.

Solution:

We are using forms authentication with our site and I found that when I gave unauthenticated users rights to the upload page, the error went away. I suspect this is because the applet does not post information the page is expecting to allow the authenticated user to the page. The page itself still has access to the session and verifies the user's credentials, but this had to be done manually.

Introduction

Like many developers, I rely heavily on the internet and other developer's experiences to solve problems I encounter. Occasionally I come across problems that I cannot easily fix either because the solution is no posted anywhere or it was not easily found. I have decided to start this blog to publish these problems and solutions, in hopes to give back to the developer community. I encourage readers to comment because many times it is in the comments that we find our solutions.

I might even post my experiences and thoughts on technologies as I feel so compelled.

You can find examples of my code on my website: Climers.com.
You can hear my podcast at: Cubertainment.com