See this blog post from Siderite Zackwehdex as well as this MSDN forum post: by default, in a Website Project, ASP.net compiles one dll per folder in an ASP.net project. So if you have the following setup:

/folder1/Control1.ascx > References Control2
/folder2/Control2.ascx > References Control3
/folder1/Control3.ascx

This means that the folder1 dll will reference the folder2 dll which will again reference the folder1 dll, causing a “circular file reference”.

Ways to fix it:

1. Rearrange the layout of your controls (or masterpages) to remove the circular references (normally this will mean moving one control to another folder – in the example above, move control2 to folder1). This is the preferred solution.
2. Use batch=”false” in the compilation tag of the web.config file. This will cause a new dll to be created for each control/page in the site. This should fix the error but is really lousy for performance, so it should be avoided (especially on production sites).

(This has happened to me a couple of times already, so posting it here as a reminder to myself for the next time).

The programming was straight-forward enough. When I first tested the feature on a few records, it worked fine. However, when I tested it on more records, it didn’t work. And when I say that it didn’t work, I am not saying that I got back some ugly .Net exception. I mean that the HTML output by the server was completely devoid of the Repeater element. It was as if it just did not exist. Somehow, when I tried the load the page with a large number of records,  some weired thing happened in IIS that just completely abandoned the rendering of the Repeater element without even providing an error message. Completely weird.

After a couple of hours of debugging, I was able to determine that the error was not related to any specific data item. Rather, it always happened when outputting the 28th DataItem in the Repeater. 27 worked fine. 28 killed it. Racking my brain (and Google), I couldn’t find any reason why this would be happening. This exact same repeater worked fine on other pages, on the live site. There was no reason I could think of why this type of failure would happen, and why it would happen here.

My coworker SeanS suggested that perhaps this was related to my dev environment, perhaps some faulty memory or something like that. There was nothing else to go on and this did explain what was going on (and I knew that the feature worked for <28 rows), so I proceeded with development. And lo and behold, when I uploaded my changes to the staging site yesterday, it worked with any number of rows without any hitch-up.

Moral of the story: weird things happen on web servers and on dev machines. Not every error that you get is related to code (especially if the error is reported by the absence of output rather than an exception). If something like this is happening to you (and it is not reproducible on other platforms), it may very well be environment-related. Test this out before wasting more time and energy trying to sort it out through the code.

I am right now in the middle of a Desktop project being written with VS.net 2005, C# and Windows Forms technology. The powers-that-be (ie: the clients) have inquired to the feasibility of potentially porting over the code to Mac or Linux. My answer has been that if it is possible, we will have to use Mono to do it, but I cannot say anything more about its compatibility until more of the programming work is completed.

The process of porting over a completed .Net Assembly to Mono just got a bit easier. A tool called MoMA (Mono Migration Analyzer) has been released (written by Jonathan Pobst) that will do the following: given any .Net assembly (.dll or .exe file) it will go through the file and report back any potential issues that may arise using the assembly with Mono (most likely a .Net 2.0 feature that has not yet been implemented, or a calls to Win32 APIs that are not documented in the .Net API). Definitely a very helpful tool in debugging a .Net aseembly that refuses to compile in Mono.

Miguel de Icaza gives a more thorough step-by-step guide and review of his experiences using MoMA (though it doesn’t seem to be too complicated).

However, we will not support Visual Studio .NET 2002 or Visual Studio .NET 2003 as development environments on Windows Vista. You can continue to use Visual Studio .NET 2002 or 2003 on Windows XP to develop applications that can run on Windows Vista.

And how will they be ensuring that VS 2005 is a great development platform for Vista?

Visual Studio 2005 SP1 will run on Vista but will likely have a few compatibility issues.

Uh huh. So the premier IDE for Microsoft development will work on the Vista with “a few compatibility issues”, while the only good IDEs for developing and maintaining ASP.net 1.1 applications will just not work. At all.

What were they thinking?

It looks like Joel Spolsky’s analysis of the situation within Microsoft has really come true. In How Microsoft Lost the API War, Joel identified two camps within Microsoft: the Raymond Chen camp, committed to maintaining software compatibility between versions of the operating system, even if it meant inserting custom API hacks just to make sure that a poorly-programmed SimCity would still work. Said Raymond:

I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.

This attitude towards maintaining program compatibility continued through XP. And we are not talking about Microsoft-developed applications, intended to make Microsoft more money. We are talking about third-party games, VB6 apps, old DOS console apps. You name it.

The other camp is the “MSDN Camp” – eternally committed to releasing (and rereleasing, and patching) the newest and greatest technology, compatibility be damned. And as Joel pointed out, starting with VB 6.0 to VB.net, IIS 5.0 to IIS 6.0, new Microsoft products were no longer fully compatible with old ones.

Which brings us to today. Microsoft has made the decision to completely abandon a program which is still used by a very large number (if not most) of programmers who develop for Microsoft technology. Why?

Given the customer feedback that we’ve received since the launch of Visual Studio 2005 indicating the manageability of upgrading from Visual Studio .NET 2003 to Visual Studio 2005, we are focusing our efforts on ensuring VS 2005 is a great development platform for Vista.

Thanks Soma. But no thanks. The migration from Asp.net 1.1 to 2.0 does not work flawlessly. And even if it did (which is probably never, for many of the very complicated webapps out there coded in 1.1), why should we? Why risk breaking something that is already working? In order to use Visual Studio 2005 on Vista, which will hopefully not have too many “compatibility issues”, and will hopefully be able to handle all of our programming needs (covering any .Net framework, as long as it is 2.0)?

No thanks. Personally, unless something drastic changes, I don’t see myself switching from XP to Vista for some time to come. And I am sure that I will not be alone.

InnerException: {“Unknown Error” }
Message: “Exception has been thrown by the target of an invocation.”
Source: “mscorlib”
StackTrace:
” at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)\r\n
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)\r\n
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args)\r\n
at System.Web.Mail.LateBoundAccessHelper.SetProp(Type type, Object obj, String propName, Object propValue)\r\n
at System.Web.Mail.LateBoundAccessHelper.SetProp(Object obj, String propName, Object propValue)”

But nothing apparently wrong there. The one weird thing that I could find is that if I set MailMessage.BodyFormat = MailFormat.Html, it would not work. If I set it to MailFormat.Text, it would work fine. Very suspicious.

In the end, the following solution worked for me. It was posted by Kyle Parker on the DotNetNuke forums:

1. Close Visual Studio
2. Open a Command Window
3. regsvr32 cdosys.dll /u
4. iisreset /restart
5. regsvr32 cdosys.dll
6. resume work in VS

After unregistering and reregistering this DLL, suddenly I was able to send Html mail again from my site. Kyle reported on his post that this only worked as a temporary solution. It is working for me so far.

Anyone know why this happened? Some other program messed up the dll that handles Html mail?

<appSettings>
  <add key="ConnectionStringName" value="ConnectionStringData" />
</appSettings>

and get access to the string in your code with something like this:

string connString = System.Configuration.ConfigurationSettings.AppSettings["ConnectionStringName"];

With ASP.net 2.0, while you can still use appsettings if you so desire, there are now subsections allowed in the Web.config, one of which is set aside for database connection strings. Here is how to use it:

<connectionStrings>
  <add name="ConnectionStringName" connectionString="ConnectionStringDetails"/>
</connectionStrings>

The good news with this is that the connection string within your Web.config file is no longer just some string (that while you may know it is a connection string, your application has no intrinsic knowledge of this). Your website can now access this string in a number of different ways, in general making your life easier (especially when using the Website Configuration screens, or any of the built-in data access controls).

All of this is old news. However, while the process for retrieving a connection string in 2.0 is well-documented when you are doing it from within the setup wizard of a DataAccess control, I had some trouble figuring out how to retrieve it solely within the code. Eventually (with some help from Google) I was able to find the exact syntax, and I am passing it on here so that it might help someone else facing the same problem.

string conn =  System.Configuration.ConfigurationManager.ConnectionStrings["ConnectionStringName"].ConnectionString;

So I installed it, as I have done on a number of computers in the past. I then went and tried to run browse the webapp in question (using http://localhost/appName) and received an HTTP 500 error (IE7 politely told me that this indicated a server error, and that the website might be under maintenance).

I tried loading a totally different webapp that had nothing to do with Crystal. Same error. Reboot, same error. Not good.

So I looked in the System Event Viewer, and saw a bunch of the following warnings:

The server failed to load application ‘/LM/W3SVC/1/Root/appName’. The error was ‘General access denied error’

OK. What is that supposed to mean? And why was it killing all of my webapps?

After a little bit of Googling, I found a page by Brett Hill in IIS Insider (March 2005), with one of the subsections titled: Resolving the Error: The server failed to load application…

The most likely cause of this problem is that the DTC coordinator service has not started. If it has started, then look in the Event Viewer for a message regarding a failed logon for the IWAM_servername account.

So I went into Services, and the Distributed Transaction Coordinator service was running. I stopped the service and restarted it, and voila, all of my sites would run again. Hopefully this situation will continue after my next reboot. If it does, the above article has some more advice on ways around this.

I have installed this program a number of times already on other machines without experiencing this error. Anyone know what may have caused it.

Technorati Tags: software-development, asp.net, ATLAS, CSS, Visual-Studio-2005, textbox, SecureString, Webservice, Performance, feed-readers, c#, interview

• Custom Paging in ASP.NET 2.0 with SQL Server 2005
• Sorting Custom Paged Results

As someone who has had to create a long stored procedure to handle custom paging in ASP.net 1.1 (create temporary table, generate query to load IDs into the table, query the temp table with some variables to pull out the records that you want), I am especially excited about the Row_Number() keyword in SQL Server 2005, and the savings in development time (debugging & headaches) that will come along with its proper use.

That said, I am getting personally excited (in a professional way) about the improved development potential with ASP.net 2.0

A few things that I have seen recently that have influenced my opinion enough to write the previous sentence:

• Scott Guthrie has posted an account of how MySpace is using ASP.net and how switching to the new platform (fresumably from ColdFusion) affected their performance:
  • They are processiong 1.5 billion page views per day, reaching 2.3 concurrent users
  • After switching to ASP.net 2.0, their server utilization went down from 85% to 27%!

  So if you are considering the platform, you wont have to be concerned about any scaling or performance issues (assuming you know what you are doing). (I wonder how php would compare, with caching and everything else. Would it even be 50% as efficient as pre-compiled code? 30%?)

• The ATLAS framework has just received a go-live license with its March CTP release. ATLAS is Microsoft’s version of Ajax for ASP.net. It may not be ROR, but if you check out this demonstration video (worth watching for both the ATLAS demo as well as the demonstration of the new improvements to the product that make development go faster) I hope you will agree that it is definitely something worth trying out.
• For just a quick taste of other features touched by the upgrade (as well as totally new additions), check out some of the webcasts on the ASP.net Developer Center

They may not ship everything on time…but once they get their products out the door, they (often?!) can really shine.