dashCommerce shut down. Now what?

Looks like the asp.net based project dashCommerce has shut it’s doors… no warning that I know of, and the whole website(s) have been replaced with a simple notice that the project no longer exists. Must have been some strange circumstances, since I’m sure a lot of people would have been interested in taking over the project instead of seeing it just (suddenly) close the doors. I have a store running the dashCommerce source, so this is a bit of concern.

So now that the pool of ecommerce solutions for asp.net has been reduced by one more, what is a .net ecommerce type to do?

I’m actually in the process of porting my dashcommerce store over to nopCommerce, which seems to now be the big boy in the space (if not the only player?).  Take a visit to www.nopcommerce.com to find out more.

What I’d really like to see is a .net ecommerce store based on the new MVC framework. The projects I’ve seen in existence seem to get hung up on tuning architecture and have no real intention of ever releasing something useful. With this in mind, I started www.mvccommerce.com some time back… no content yet at time of writing this. The project is registered with codeplex  ( http://mvccommerce.codeplex.com) and will be looking for devs. If you just want to keep an eye on it, follow it at twitter – http://twitter.com/mvccommerce

I’m also a fan (and a dev for) MVCCMS, which has ecommerce capabilities coming soon, so you may want to take a look at it as well, at www.mvccms.com .

But for getting your (open source asp.net) store open asap, looks like nopCommerce will be the way to go for a while.   Add your comments if you have any other recommendations I may have overlooked.


Debug Windows Mobile with webservices with Fiddler – part 2

 The day following my posting the original “using fiddler” info (see this ), I got to try my same setup using a windows mobile 5 pda… and failed.

I won’t go into all the things I tried to get this to work again, but FINALLY found the right combo to allow a locally-connected PDA (via activesync) to connect to a webservice running in the visual studio development webserver.

WM5+ apparently no longer likes to use the ppp_peer name for accessing the locally connected pc. I’ve read there is a replacement called dtpt_peer that should work, but so far this one is batting zero. Instead, you can use an IP that gets configged automatically by activesync. I wish there were a name to use in place of the ip, but if there is one, i havent found it.

Basically:  is the IP given to the desktop pc. is the ip given to the PDA.

Why not just use this IP in place of ppp_peer and get busy? Well windows on the desktop also treats these ip’s differently from the normal local ip, and when a connection is made through them, they are treated as remote connections.

Step 1. Let’s configure Fiddler to accept external IP’s. Note: the method I used will allow connections from *anywhere*, which is a bit dangerous as it could allow others to use your proxy and do bad-people stuff through it. You should really configure fiddler to only allow remote connections from the 169.254.2.* range.

Check this box:

enable remote connections

enable remote connections

Restart fiddler and your personal firewall will likely warn that fiddler wants to accept connections on port 8888, tell it yes that’s cool. Really, the personal firewall is a better place to go set some rules regarding the allowable ip range mentioned above.

Step 2. Add some script code to fiddler. Open the script editor and add this to the event called OnBeforeRequest, replacing the port 1234 with the appropriate one (the one web development server dynamically assigns):

if (oSession.host==”″){

This entry will take the “remote” connection from the 169 ip and make it look like a local connection that the dev server will be happy with accepting.

Step 3. Setup the connection on the pda to use a proxy, and put the for the proxy ip. For the http proxy portion, specify port 8888.

Step 4. Now open a browser on the PDA and connect to: http://localhost.:1234 , again replacing the port 1234 with your own. Yes, that is a “.” between localhost and the “:”. Go read on the fiddler website about it, I dont understand it either. If things work, fiddler should show your connection attempt in its log, and your mobile browser should show the locally hosted web content.

Now, you can use this same url scheme with your webservice calls from the PDA.

Warning! I also tried this same setup today with a compact framework 1.0 app. It *almost* worked, but the older CF.Net trimmed off the port number portion and thus was trying to hit port 80… and failed. As soon as I upgraded to cf.net 3.5, everything worked fine, and Im sure cf.net 2.0 is ok as well, though I should know better than to be sure of anything at all with winmo and CF.net dev 😉

Debug Windows Mobile with webservices on localhost using Visual Studio Web Development Server and Fiddler

This has frustrated me for a while, but seems I found a solution this evening.
I build a lot of Compact Framework apps which communicate via webservices with an asp.net webservice. During development, I prefer to use the built-in web development server instead of having to mess around with IIS etc.

The problem: the web dev server only allows connections from “localhost”, which doesnt include your dev pda, assuming you are using activesync. Long story, but even though the pda can browse the web using your desktop’s ip, it has it’s own local ip which makes the dev web server think it is a remote connection. Thus is winds up blocked.

Solution seems to be, download this tool: http://www.fiddlertool.com
Fiddler is a local proxy which is used for debugging http connections, and is normally used along with asp.net development.

You can disable the logging in fiddler so we’re just using it as a local proxy.

On your windows mobile device, add an http proxy to the connection settings. Use port 8888 (the fiddler default), and use ppp_peer as the host name. Im told that windows mobile 5 and greater use dtpt_peer instead, but I havent tested this yet.

NOW: when you wish to connect to a locally hosted web app or web service from the pda, use this:


where 1234 is your port number and.. you get the idea. *But* notice the single “.” after localhost. This is the magic that makes this work. How? Well, I’ve fought this battle long enough, discovering why is a luxury I don’t have at the moment.

ASP.Net formview – gripe of the day

I upgraded an asp.net project today to switch from a DetailsView control to a FormView control. Obviously I needed editing capabilities, thus the reason.

The upgrade reminded me of a major gripe I have with the FormView control. When you associate the control with a datasource, it will auto-generate a tabular form view of your data, in a list of Name: Value format. Really what it is doing is just creating a quicky view of the fields in your datasource and throwing the generated fields into the 3 templates needed (ItemTemplate, EditTemplate, and InsertTemplate) so you can have them handy for all that extra formatting you are expected to want to perform.

One formatting difference between the auto-generated code this control produces versus the format of the simpler DetailsView is, the DetailsView produces table elements so that all the “Name” elements show up in a single table column followed by the “Values” column. This is a nice formatted and is usually pretty close to what you would want to create in a list of values.

The FormView however assumes you are going to do a lot of editing of the templates, and so doesnt include any layout except the basics- Just the Name, “:” , and the bound feld value.  This results in the Name and Value getting bunched together up on the left side and results in a truly ugly form.

Not too difficult to format these into a table if you want to, right? Well sure… but after building a few apps using this, it can drive you nuts. Some of the apps Ive worked on have, say, an average of 30 fields to present on the screen. After I generate the FormView from the datasource, I then have to go add table TR/TD code around every element… 3 times. So those 30 elements are tripled to 90 elements. Each of the 90 elements has to have an opening TR/TD, then a middle TD/TD, then a finished TD/TR. So we are now looking at having to cut n paste about 270 items and try to make sure you didnt fubar anything.

To make things worse, if you make a schema change in your database (and who doesnt), you pretty much need to regen the thing and start over. 

AND: This is just ONE FormView. One app I recently finished had at least 20 FormViews in it. Neglecting any rebuilds, this is around 5000 elements I had to hand edit. Deadline? You talk funny.

I understand MS’es thinking in this, and I would probably be much worse off if I were in the other boat and had to *remove* all these unwanted table elements every time a Formview is generated… but why not offer an option to include a basic table formatting? Or even allow for custom formatting of the generated code so we can include our own tags or whatever markup is desired. I even researched to see if it’s possible to create my own generator for this to override or replace the one Visual Studio uses… found some obscure stuff but nothing really useful.

I’d like to hear if anyone has any pointers on this.