Ambrosian Scripture

DLinq is an ORM

Ambrose — Tue, 04 Oct 2005 22:26:00 GMT

I just ran across this thread on TSS.NET. I found it somewhat curious that there is a Microsoft guy on there claiming that DLinq is not an ORM. While I don't doubt there's a way to construe the definition of ORM to make it not true (as the MS guys seems to try), I think that's counterproductive and just plain silly. As one of the commenters said, it looks and feels like an ORM, so why not just call it that?

At the MVP Summit, it was confirmed that LINQ will support extensibility into third-party tools via expression trees. The problem is first that they don't have that stuff documented and second that they plan to change it. This was gleaned in a session on DLinq where the product team was looking for feedback. They're very concerned about getting feedback, as Dinesh has illustrated, about DLinq, but I think that they need to first focus on getting their API for extending LINQ (a la expression tree structures and the like) solidified and documented ASAP.

On that note, I've talked to Paul Wilson here at the ASPInsiders Summit about DLinq and the aforementioned blog by Dinesh. Both of us have written ORMs, and both of us have commented on Dinesh's blog. However, you'll note, neither of our comments have shown up. I'm not sure what that's all about, but if you have feedback for the LINQ or DLinq team, you can post it on this post on dotNetTemplar, and I'll make sure that the related teams are aware of it. Now is the time to give your feedback on these products as they are early enough in the design cycle and are focused on that feedback.

Project Rally: Episode II

Ambrose — Wed, 27 Apr 2005 02:41:00 GMT

Not for the feint of heart...

Moving Blog...

Ambrose — Wed, 27 Oct 2004 22:46:00 GMT

For those of you strange enough to read my musings, I invite you to meander on over to my new blog. That will be my primary pad for communication with the rest of creation going forward.

NUnitAsp and NUnit 2.2 Don't Get Along

Ambrose — Tue, 19 Oct 2004 22:33:00 GMT

NUnit (well, NUnitAsp, actually) just ran me for a loop. I had not loaded this particular test project for a while (since I upgraded to NUnit 2.2), and when I tried to load it up, I got the following:

System.IO.FileNotFoundException: File or assembly name nunit.framework, or one of its dependencies, was not found.
Server stack trace:
   at System.Reflection.Assembly.GetExportedTypes()
   at NUnit.Core.TestSuiteBuilder.Build(String assemblyName, Int32 assemblyKey)
   at NUnit.Core.TestSuiteBuilder.Build(String projectName, IList assemblies)
   at NUnit.Core.RemoteTestRunner.Load(String projectName, String[] assemblies)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(MethodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at NUnit.Core.TestRunner.Load(String projectName, String[] assemblies)
   at NUnit.Util.TestDomain.Load(String testFileName, String appBase, String configFile, String binPath, String[] assemblies, String testFixture)
   at NUnit.Util.TestDomain.Load(NUnitProject project, String testFixture)
   at NUnit.Util.TestLoader.LoadTest(String testName)

Now, initially I thought it'd be something to do with my project references, even though that didn't really make sense, so I tried removing my nunit.framework reference and readding. No luck. But thanks to Google, I saw the words "NunitAsp" and thought, "aha! that must be it.. I'll just go get the latest version of NUnitAsp and install it."

No beans. Apparently the good folks developing that project haven't bothered to rebuild with the new version of NUnit. So, after pondering the problem for a minute, I decided to just go get an old version of NUnit and stick it in the GAC. After all, that's what it's for, right? Running multiple versions of the same product?

So I went to NUnit's site on sourceforge and blundered around a bit (I only go there to download stuff occassionally) and finally came back to NUnit.org, where they nicely offered the older (2.1) version for download as MSI or source.

Since I only wanted the framework DLL (and not another GUI et al), I downloaded the source zip first, hoping they included a built DLL (to save me the trouble of building it). Uh uh.. So I tried MSI.. nope, that won't install over a newer version.

SO, back to the source zip. Unzip, open in VS, build in Release mode, and then drag-n-drop the nunit.framework.dll to the GAC.

Joy, rapture, etc. etc., the old NUnit test project now opens and runs fine. I guess this goes to show, in case we didn't know it, we still can run into DLL versioning problems, especially when we're dependent on 3rd parties. All in all, it was no big deal, but it was a tiny bit frustrating. Now if only the nice NUnitAsp people will update their build.

Updated Advice on ASP.NET Security Issue

Ambrose — Fri, 08 Oct 2004 00:59:00 GMT

As directed here, you need to go to this page to get the latest on the recently-discovered ASP.NET vulnerability. Microsoft has now released an HTTP module that should protect the apps on your servers, and it has a handy installer to make it easy for you. They have been working hard over the last week to make this tool as easy and solid as possible. If you have any problems, please let them know.

Just Doing My Part

Ambrose — Wed, 06 Oct 2004 20:26:00 GMT

Trying to help spread the word...

http://www.microsoft.com/security/incident/aspnet.mspx

Your Servers are at Risk!

Ambrose — Wed, 29 Sep 2004 14:32:00 GMT

If you are running applications on IIS 5 or 5.1 and have not run the IIS Lockdown tool and installed URLScan, you are just asking for trouble.

Please, for the sake of your clients, self, and company, be sure to at least do these simple steps to further secure your web servers. These things are so easy to do, you have no excuse.

While you're at it, check out the IIS 5 security checklist!

Event Handler Declarations in Whidbey

Ambrose — Wed, 15 Sep 2004 15:32:00 GMT

Teemu and Andy have started an interesting discussion about event handler declarations in ASP.NET Whidbey, particularly relating to VS/VWD 2005. Since I originally voted on the bug report that started it, I thought I'd chime in with further clarification for my part.

First of all, I think I may have misunderstood what Teemu was saying when he directed me to the bug report. I was under the impression that it was stuffing the actual handler methods inline in the ASPX (in a server-side script block) instead of in the code separation file. Since I'm lazy (err.. efficient), I haven't bothered actually testing it out. :) I hope we can all agree that this would be a bad thing, and that's what I was thinking when I acquiesced and voted. I still think the report indicates that, but based on Andy's comments, I'm not so sure.

Anyways, I would still suggest that the designer can only be responsible for the initial declaration, i.e., where we first say "hey, I want to handle x event for this control." At that point, it knows exactly where in the control hierarchy that the control is, so it should be able to correctly attach the event in code for us.

Typically, we are talking about a top-level control, so it's a simple matter of myControl.MyEvent += new MyEventHandler(this.DoMyEvent); in the OnInit method (or Handles myControl.MyEvent, if you prefer). However, let's say it's in a repeater template. In that case, it can create an ItemCreated handler in which it attaches the appropriate event handler in code for each item. In any case, if you move the control in the hierarchy after the fact, I don't think the designer should adjust it for you (simply because I tend to think it would screw up).

Having said all of that, the ASP.NET model has grown ever more towards putting controller code into the ASPX tags with this new version. I used to be something of a purist when it comes to separating UI design from control, but I think I have to move on, since that is the direction of things. More often than not, going with the flow makes your job easier, so instead of raging against the machine, I will just become one with the borg. After taking that plunge, it is easy to see that letting ASP.NET parse out my event handler hookups is the easier way to go. At least, if we can't agree on anything else, we should be consistent.

VS Live! Community Lounge

Ambrose — Mon, 13 Sep 2004 19:57:00 GMT

Just a heads up to VS Live attendees. If you have any problems that have been bugging you for a while, or if you just want to hang out, stop by the "community lounge" in the exhibition hall and have a chat. The times are as follows:

Monday, Sep 13, 2004: 12:30 pm – 4:00 pm
Tuesday, Sep 14, 2004: 12:00 pm – 3:00 pm and 6:00 pm – 8:00 pm (Evening Reception)
Wednesday, Sep 15, 2004: 11:00 am – 2:00 pm

Hope to see you there!

Pimp My Ride!

Ambrose — Sun, 12 Sep 2004 23:08:00 GMT

So I finally took the plunge and forked over the dough for some custom rims on my 6th generation Celica (much better looking than the 7th!). After a few hours, the look of the ride is sooo much nicer. Check it out here!