ASP.NET will kick off a little profile thingy when it finds a <property> section. It appears to go into the ASP.NET Temporary Folder. It seems to be a private method in ProfileBase that loads this.

Some errors that happen:
Sometimes deleting the <property> section and readding it works. This happens all the time for all sorts of reasons, not just profile related, but dynamic compilation and shadow assembly related.

ProfileCommon not available- this is supposed to be compiled either at design time, run time or sometime. It fails to work in a variety of circumstances.

Precompiled apps can have problems with the ProfileBase class
Ambiguous reference errors- can happen when App_Code.Compiled or PrecompiledApp.config exist or fail to exist and ProfileCommon gets compiled twice.
Similarly copying the bin of the new version into the bin of the old is bad. You get a blended set of .dlls
Deleting files in ASP.NET Temporary Files sometimes works.

Interestingly, all the above don’t seem to be addressable by writing a custom provider. It doesn’t seem possible to override the settings part, where it reads web.config and starts trying to create that problematic ProfileCommon.

Conclusion
It turned out to be a dll that was referencing a native dll that wasn’t on the PATH. The profile was just triggering a compile. The compile then check references for everything in the \bin\ folder, even if the profile or invoked page isn’t using it. Oddly, this doesn’t happen on every single page, so there are some code paths where ASP.NET doesn’t feel the need to recompile every !@#$@!#$ thing in the world. This, I suppose is good or else we’d see pathalogical compile churning.

I diagnosed this by watching the list of assemblies that were getting loaded in Visual Studio while the debugger was attached. If it couldn’t load symbols or if it was obviously a COM dll, I considered it a candidate and finally narrowed it down to a SMO library, which happens to have non-managed dependencies.

The official line for WCF and webservices is that they are for interop especially between organizations and between different technology stacks, e.g. Java and .NET or COBOL and .NET.

Who wants to build an open API when no one has asked for it? Who will ask for an open API if one doesn’t already exist?  For WCF/webservices to happen at all you have to image a use case for these that would be useful now.

Three reason why you’d wan’t to consume your own webservices:

Javascript to .NET interop.  This allows for Aptana driven development against a C# application.  This becomes especially compelling if you have webservices returning JSON,  and RSS, because the client will be simpler to write.

Testability.  The webservices API is more testable than the webforms that do much the same thing.

Data access.  XML is a datatype too.  It can be handy to have one more dataformat in the data monkey’s toolbox.

Compatibility with future versions. WCF especially- The web service as a programming model might be low performance, but it is remarkably resiliant to changes in implementation.  So much thought has gone into defining an interface that works with everyone, it will even work with that foreign application called “Your Application, version next”

You probably store this in the database as a table.  It could also have been column constrain, although a column constraint won’t let you run a select. None of these easly allow you to treat the reference table as an enum in C#, unless you use code generation.

Worst
Create Table  States_Ref (Id int, Description Varchar(50))

The code is numeric,  so humans can’t look at raw tables to see data problems.  The data type is too large.  Worse would be bigint, or worst of all, just using image as a datatype in case there are a google of different states.  If all reference tables use Id/Description, then select queries go from

Select customer_id, state_id, type_id, category_id … etc

to

Select customer_id, t1.description, t2.description, t3.description… and now all queries require alias. Ugh.

Better
Create Table  States_Ref (States char(2), Description Varchar(200)).  Everyone can memorize CO, no one can memorize that 31 means Colorado.  Obviously, alphanumeric codes are for the maintenance developers and uber-power users.  If your users are brain damaged, the actual reference value would be hidden.  In the real world, IT staff will eventually have to learn many of the numeric codes (But don’t get clever with alpha codes, don’t embed a mini-db into the codes, like CO_MTN_STATE_US.)

Best
Create Table  States_Ref (States char(2), State_Name Varchar(200), State_Name_Short Varchar(50), Active bit)

The alphanumeric codes are space efficient and human memorizable.  The Active bit allows certain codes to be phase out without going back to legacy data and changing the old code.  The descriptive columns include the table name (In data tables, ie. not reference tables, I wouldn’t add the table name to every column, though)

C# and ASP.NET
Bad: Put the drop down list into a DataSet, reload every time.
Better Yet: Put the list into a Sorted Dictionary or Sorted List. (And do the sorting server side in SQL 1st of course), reload everyt time.
Better Yet: Batch up requests for reference tables, return them all at once in a multi query  result set.
Best: Put the Sorted Dictionary into the ASP.NET Cache (Or viewstate at least).   DataSets and DataTables both are too big.  Don’t cache the user control– it causes peculiar behaviors

UI-
Worst- Dropdowns that require a mouse to search and select.
Better- List boxes that allow viewing all rows (sometimes the list is too long and screen space to sparse, but if you can, show all the items)
Best- JavaScript instant filters for long lists

Binding-
Worst- Fail to load or show a blank if the value is no longer Valid
Best- Add value to list if binding and the value isn’t on the list.

Any more ideas?

Long ago I was happy.  I always used the SqlDataSource and my GridViews bound with all the features I could ever want.   I didn’t have to write 1000s of lines of code to page and sort.  It worked so well, I mistakenly thought the magic was due to the GridView or the xxxDataSource technology.  Actually, the paging and sorting is irregularlly implemented depending on datasource.

New datasources appeared on the scene, like SQLite, SQL Compact, and data generated data access layers, like SubSonic.  I realized that as soon as you bind to an ObjectDataSource, a dataset/datatable, you are responsible for paging and sorting.  At best you’ll be able to register all your grids to some common code. (I gotta look up that link for the technique)– you quickly find yourself back in the world of the DataGrid, with 1000s of lines of code to write.

Now I’m thinking everyone should pick a grid that at minimum supports paging and sorting.  I’m choosing Telerik’s grid, which can sort and page any datasource so long as you use the NeedData event for binding.

Telerik Ajax on my machine on my project was acting as if on MSIE, but not firefox, as if postbacks were GET’s. Page.IsPostback evaluated to false.

But! If I changed from http://localhost/mysite/MyPageWithTelerikDropDown.aspx

to http://machinename/…etc

Then post backs behaved like postbacks.

Go figure.

Tags: Telerik

Wow, this class has too many properties and is way to unstable with respect to the reality-object impedance mismatch.

I beseech the developer community to swear to never use #region or #endregion blocks again, except for possibly machine generated code.

The first step is to stop typing #region and #endregion. This will greatly improve the transparency of your code. Next, because you are the sort of person that uses #region and #endregion to hide the code you are ashamed of– go find all those HACK:, BUG:, and CRAP: comments.

Lets say you have a public folder, where users can upload files.  To ensure users can’t upload and execute any code that the .NET compiler can interpret and run, add a we.config file that has errors in it. That will stop any code in that folder from running, malicious or otherwise.