"WebForm_DoPostBackWithOptions not defined"

Specifically, I have an ImageButton control that when clicked is supposed to auto-postback and call a server-side function, in this case a "Logout".

I'm in the process of branching code from one deployment revision into a "Work In Progress (WIP)" directory for the next phase. In doing so, I had to set up an IIS virtual directory and copy all the necessary code there. With that done, I noticed that when clicking on the button, the desired logout mechanism was broken in the WIP. Thanks to the Firefox Javascript Console, I saw the message above and was able to track the problem down.

Even more maddening, for the site I'm working on we use the ComponentArt Suite and all of the functionality related to the Grid control stopped working. All the grids would load their items just fine, but would only display a small box where the grid should have been. As I said, this is the third time this has happened to me, and each time I forget what I did to fix the problem. So this is kind of like a bookmark for me. Hopefully it'll be useful to someone else.

I'm using IIS on Windows XP Professional SP2. Bring up IIS and right-click on your virtual directory. Select "Properties". On the Virtual Directory tab in the Application Settings section, click the "Configuration" button. This brings up the "Mappings" tab. Highlight the entry for ".axd" and click "Edit". Be sure that the lower left-hand checkbox for "Check that File Exists" is unchecked! If not, uncheck it and click "OK". The WebResource.axd references you see when doing "View Source" on a .NET webpage don't actually link to a physical file, so if this box is checked then the scripts don't get loaded correctly.

So there you have it.

Note that I have worked my entire IT career in the internet space, so that's the perspective from which this blurb derives. This may not be as relevant to people writing .NET apps for packaged and/or client-server apps.

Well I'll outline the way I've worked with namespaces up to this point. We decided a long time ago at {previous employer name removed} that unless we were going to be building packaged software deployed to millions of end-user machines, the GAC (Global Assembly Cache) is NOT the way to go. Instead, we employed a strategy to keep the AssemblyVersion numbers the same on all our assemblies and instead incrementing the AssemblyFileVersion. You can find both of these settings in the AssemblyInfo.cs of your namespace project. The AssemblyVersion is what other assemblies that reference your namespace will look at. If that number changes, then the referencing assembly blows up. But you as the developer still need to know what version of the assembly is deployed, and for that you use the AssemblyFileVersion attribute. Increment it every time a new version of the assembly is deployed.

The same goes for giving your assemblies a strong name. If you aren't going to put them in the GAC, and you will always be deploying them on in-house machines, then forget about strong naming.

Next, as for deciding what goes into the namespaces, I'm pretty strict where I currently work about designing namespaces such that if a disaster happened and we only had the source code files, we need to be able to recompile from scratch. This means no circular references amongst your namespaces such as:

Namespace A references Namespace B and vice versa

Indirectly, this actually leads to a purer form of OOA/D because you really have to use some interesting indirection to get to your end result...which is what design patterns are all about. You can't always avoid this gotcha, and refactoring namespaces to eliminate circular references can be a real bitch after they're all set up and running. Keep in mind that one assembly can contain multiple namespaces if you simply cannot decouple relationships. Just remember not to put too much functionality into one namespace or else it can become a bottleneck with concurrent projects.

I would recommend starting with the most fundamental part of your whole architecutre -- the data access layer. Chances are everything will need to access it, so start there. Put it in an assembly like CompanyName.Data.dll or some such. It's also handy to think about your namespace tree like ever refining nodes on a functionality tree.

Example (these are all namespaces):
CompanyName
CompanyName.Data
CompanyName.Common
CompanyName.Customer
CompanyName.Web.UI
CompanyName.Web.UI.Public
CompanyName.Web.UI.Private
CompanyName.Web.UI.Admin
CompanyName.Web.UI.Admin.Reports

and so on. The nodes lower in the tree can have visibility to the classes higher up, but the reverse must NEVER happen. You're always working from the general to the specific.

With regard to ASP.NET, every environment I've worked in has done JIT deployment over pre-compiled deployment. There are trade offs to both of course, but JIT seems to allow you to respond to changes quicker without having to deploy alot of unneccesary code. Additionally, all your assemblies will go in the \bin directory of the web server where the runtime will automatically find them when you instantiate objects from your code-behinds. One item in favor of pre-compiled is that, depending on the amount of traffic you're serving from your website, JIT compilation in real-time of code updates might actually crash the webserver if your traffic load is too high. I've seen it happen where I work now.

If you don't already have a copy, you simply MUST buy a copy of Applied .NET Framework Programming by Jeffrey Richter. While it doesn't cover design concepts, it's got more information than you'll ever need about the internals of the .NET Framework and CLR.

I needed to obtain a list of active users who had a particular string within a CLOB field in an auxillary table associated back to their account via a foreign key. You can't do "LIKE" statements against a CLOB, and we don't have Intermedia operational on the boxes where the query needed to run so I couldn't run a "contains" against an index. I say "boxes" because we have two distinct user databases -- one running Oracle 9i and another on 8i. So whatever solution I came up with had to play in both environments. Our DBA mentioned there was a package resident in both called DBMS_LOB which exposed methods for working with LOBs. I saw that one of these was InStr() and hoped that it would allow me to specify the substring I was concerned with, and perhaps return the index where the substring started within the CLOB.

Sometimes there IS reason in the universe. I was able to do this using the following PL/SQL (names have been changed to protect the innocent):

select u.user_uid, u.login_text, p.profile_name_text
  from profile p, user u
 where u.acct_closed_ind = 0
   and u.user_uid = p.user_uid
   and (
dbms_lob.instr(clob_field, 'first string to find',1,1) > 0 or
        dbms_lob.instr(clob_field, 'second string to find',1,1) > 0
);

Obviously you could stick as many substrings in there as you want using additional ORs. The DBMS_LOB package has all kinds of interesting functions for dealing LOBs. We could have even run a script to update/remove the offending strings automatically. But we opted for safety and will instead have the Customer Support team call the users so they can be educated.

I've been an internet developer for almost 9 years now, and most of that time I've spent in a Microsoft environment. Very briefly at the start of my career, I worked for an ISP writing an in-house accounting package to keep up with things like billing, subscribers, hosting, disk usage, etc. Since the user accounts were all on Sun UltraSPARC servers, I did some C programming on Solaris. Other than that, it's been Windows all the way.

Currently, I'm a software architect for an internet E-commerce firm in Atlanta, GA. I've been using Microsoft's .NET platform since it was in Beta 1 and frankly, I love it! Once I got fully into how you could architect systems using full-blown OOA/D, the whole scripting world totally lost its luster. That goes for Visual Basic as well. In .NET I made a conscious choice to use C# because of its more standard syntax. I figured if I wanted to go into an environment that heavily utilized OO development strategies, the folks I'd encounter would've most likely used Java or C++.

So recently I started working on a project in my spare time that hopefully I'll be able to make a little money at someday. When the time came to decide which technology am was going to use, I found myself leaning toward Java despite my clear Microsoft preference. I had previously tried to start a venture with a friend where we were going to use .NET. As a small outfit of two guys, we found an ASP.NET hosting provider for a reasonable price. But the problem came when we had to access the tools and database platform. Of course we could put our hands on copies of SQL Server 2000 and VS.NET 2002, but it wouldn't have necessarily been above board. There's a huge cost to starting up a venture if you want to remain legal in the Microsoft environment. How many of you out there have paid for your home computer's installation of Office2003? Chances are you just used your company's MSDN disk.

I didn't want to go the piracy route, and that made the Java environment very attractive. I downloaded the J2EE environment from java.sun.com and also the latest IDE from NetBeans, and away I went. There are some idiosyncracies to learn in transitioning to this new mindset. Clearly the tools aren't as seemless as Visual Studio, and there's alot more of sticking your fingers in the goo of your environment to make sure everything's integrated. But the tools are getting better about hiding that from the user to maximize productivity. Additionally, I downloaded MySQL which is a free database application that will be perfect for the amount of volume I expect to handle initially. In working with the Java language itself, there's a learning curve in trying to familiarize myself with all the capabilities of the SDK packages, as well as the keywords for implementing interfaces and extending base/abstract classes (makes sense though when you use those keywords in a sentence ;-) ) or overriding methods.

I guess my point is I never thought I'd be taking a peek behind this curtain to see how the other half lives. So far it ain't too bad. I think Microsoft has a real problem in that their tools are prohibitively expensive for someone like me who wants to start his own company without outside investors or alot of cash. I don't have thousands of dollars to license everything I'd need, and I'm not one to steal. Sorry. Free is better at this point. Not only that, in selling what I develop to my target audience of NFP organizations, they're not going to want to pay Microsoft licensing fees either to provide my application an environment. And once I've got my platform functioning, I'm probably going to be loathe to switch to Microsoft, even though I think .NET is great. We'll see.