Have you tried item[@xsi:type='ns:AAA'] as the match attribute?

Hmm. CodeProject has rendered the escaped characters ... Try again & - & " - " < - < > - >

If the xml file contains these special characters, it is not valid xml. You will need to replace these characters with their escaped verions. Have a look in MSDN or on www.w3c.org for the complete list. Some I can remember are; & - & " - " < - < > - >

You can replace the aspx file at run-time, so I don't think that you are running into problems with the file being locked. Have you checked that the ASPNET user have the necessarysecurity permissions to access the apsx file for writing? I know that this user is fairly well tied down by default, and may only have read access. Try adding the user on the security tab of the file properties dialog. Regards Mark Smithson

I think that any function called from a delegate will normally be executed on a thread from the thread pool. Thus it will not be executed on Thread A or Thread B. I have some memory of a way of getting a delegate to execute on a particular thread, but can't recall the details right now.

If all the values match, except for case then you could try using Enum.Parse() to get the correct enum value and then outputting the name into the code you are generating.

Does this work for you? textWriter.WriteStartDocument(); textWriter.WriteStartElement("", "MAIN TAG", ""); textWriter.WriteStartElement("", "TAG", ""); textWriter.WriteString("STUFF"); textWriter.WriteEndElement(); textWriter.WriteStartElement("", "TAG", ""); textWriter.WriteString("STUFF2"); textWriter.WriteEndElement(); textWriter.WriteEndElement(); textWriter.Flush();

OK Well the only thing I can think of is that the trace shows the '404' requests are to the /Images directory not /AMPOC/Images. Have you tried creating an application called Images and adding the handler there as well? Alternatively can you add your handler to the root web application, or is the server used for other things as well? I hope this works ;-) Regards Mark Smithson

That sounds about right. I would just point out that assemblies run from a network share will have reduced permissions when using the default security settings for .NET. Depending on what your assemblies do, you may need to alter these settings to give your assemblies the necessary permissions. Regards Mark Smithson

How are you trying do it, and what errors are you getting?

Aha! When you register your handler with IIS (Application Mapping Dialog) there is a checkbox option to "Check that file exists". If this is checked IIS will probably return a not found (404) exception. Regards Mark Smithson

I'm not really sure what you mean by 'loaded and working'. You code and the errors imply that the CLR cannot load a type. This is because your plugin directory is not in the probing path for the application. Your will either need to change your applications config file to include this directory, or manually load the assemblies. Try adding the following to your app.config file

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="plugins"/>
</assemblyBinding>
</runtime>
</configuration>

Also have a look at the following MSDN link for further information on the how the CLR locates assemblies http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp Regards Mark Smithson

Hmm, Your handler appears to be registered at the appropriate location, and should be intercepting all requests for your application. I have the following comments and suggestions that may help you to get to the source of the problem. Have a look at the source in your browser to confirm that the urls being requested point to your server, or are relative to the page. Try turning on logging in IIS on both servers to confirm which servers are receiving the requests. Just to confirm that I understand what you are doing. You are intercepting all incoming requests, getting the content stream from a remote server using HttpWebRequest and writing the response to the response stream of your clients request. I presume that you have reasons for not doing a Response.Redirect to the other server. If you want some information on the filter stream, I can try and find the article I read about it in. You are correct in that it would be a pain to find and replace all the urls, and I would probably persist with trying to get your solution to work. Regards Mark Smithson

I don't think your problem has to do with threading. It doesn't matter on which thread you are trying to create the object, the CLR cannot find the assembly file that the object is defined in. Which files do you have as part of your application? Presumably you have an application exe and the GoogleSearch.dll is the plugin. Is the GoogleSearch dll located at any of the locations in the output above? If so is the dll of the same version listed above (i.e. 1.0.1212.29205)? Regards Mark Smithson

Have you made sure that the second document is valid xml? The best way to do this would be to load the document in internet explorer. You will get an error if the document is not valid. What exception message are you getting when the code crashes? This can usually lead you to the source of the problem. Regards Mark Smithson

Is your handler registered for the other applications? If you have a url like "../Images/go.gif" where the page url is "http://server/thisapp/pages/mypage.aspx", then the request for the image will be sent to "http://server/thisapp/Images/go.gif". If your httphandler is registered for an application at the "pages" level, you will not see the request as it is not targeted for your application. If this is the case you may be able to register your handler at the higher level ("thisapp" in this example). If this is not possible, your handler may be able to replace all the urls in the page response. I think you can use a filtered stream to alter the page output in a HttpHandler. Regards Mark Smithson

Editing the location uri in the WSDL file would tell clients to connect to the web service using a different port if they parse the wsdl file (The COM Web Service client and the javascript client do parse this file). This allows the trace utility to intercept the SOAP messages. ASP.NET generates the wsdl document based on the port that the client is connecting on. Hence if you connect to your web service using http://server:8080/webservice/ws.asmx?wsdl, the wsdl document will have the same url in the location attribute. Are your web service clients developed using the "add web reference" in Visual Studio? If so the url (including the port) of the web service will be hard coded, unless you changed the "URL Behavior" of the reference to Dynamic. The clients will always try and connect on that url. If you chose Dynamic, then you can alter the [application].config files for the client to point to a different port ('8080' for the trace tool). If you can not control the url clients use to connect (if you are using the COM client for example) you could try pointing the clients at a copy of the wsdl file that has the location attribute updated to point to the relevant url and port as required by the trace utility. I hope this helps Regards Mark Smithson

Javascript running in IE is not allowed to access the file system of the local machine. Why are you trying to save the document, is there another way you can get the same result? Regards Mark Smithson

One thing that is wrong is that the filename strings are not properly escaped. Try changing string filename="D:\test.xml" to string filename=@"D:\test.xml" or string filename=@"D:\\test.xml" You will also need to do the same for "D:\Options.xml" "\t" will translate to a tab character, which will cause the load of the first document to fail as it can not find the file, or possibly that the filename is invalid. Another problem is that when you are loading the second document you are using LoadXml and not Load. "D:\Options.xml" is not a valid xml string. I have made both these mistakes far too many times myself :wtf: Regards Mark Smithson

It is not clear from you post if the queries execute against different databases. If they don't you may like to consider the following (if, indeed you haven't already). Running two consecutive queries will cause some slowdown, due to the server having to perform additional work. I would make sure that your long running query is not obtaining any locks that may prevent the other query from running. If your queries perform any joins you may find that the joins cause locks. I also remember reading somewhere that SQL Server/MSDE will escalate locks. Perhaps you are getting page locks that are causing the second query to block, as it has data on the same page. Have you tried moving the database(s) to a SQL Server (not MSDE) to see if you still get the same problem? With regards to the performance of MSDE, it will slow down if you have more than '5 concurrent batch workloads'. have a look at the performance section in this page for further information. http://www.microsoft.com/sql/techinfo/development/2000/MSDE2000.asp I hope this helps. Regards Mark Smithson