FearTheCowboy -- Garrett Serack's blog - Latest Comments

Re: Fixing WebRequest’s desire to throw exceptions instead of returning status

David Sutton — Wed, 04 Apr 2012 12:02:47 -0000

In my experience so far today (Framework 4, VS 2010) it's returning 404 errors even on good URLs.I can use the debug Immediate window to verify the URL, copy it and paste it into my browser.In the browser the URL comes up just fine.
The webRequest is somehow trashing the URL:

The code:
ohrRequest = (HttpWebRequest)WebRequest.Create(sURL); //<- this is the URL I can type into the browser and get it. ohrRequest.AllowAutoRedirect = _allowAutoRedirect; ohrRequest.Method = "GET"; if(wProxy != null) ohrRequest.Proxy = wProxy; ohrRequest.Headers["Cookie"] = getCookieHeader(); HttpWebResponse ohrResponse = (HttpWebResponse)ohrRequest.GetResponse(); return handleResponse(ohrResponse);

As you pointed out it throws an error on the GetResponse() line.CLASSIC MICROSOFT - STUPID

Re: Fixing WebRequest’s desire to throw exceptions instead of returning status

Srinath Janakiraman — Mon, 02 Jan 2012 05:57:34 -0000

nice post dude...

Re: Fixing WebRequest’s desire to throw exceptions instead of returning status

Garrett Serack — Fri, 02 Sep 2011 20:57:21 -0000

Just switched to Disqus for comments. Testing now.

Re: We’ve Moved CoApp code hosting to Github

Christof Jans — Wed, 27 Apr 2011 16:50:19 -0000

As a certifiable git/github zealot/fanboy I am tickled pink with your decision :P

Re: We’ve Moved CoApp code hosting to Github

Garrett Serack — Tue, 26 Apr 2011 20:00:59 -0000

Well, *personally* I prefer the command line anyway, and it's not like I had a prior preference with hg.

And, actually, I was trying the hg-git stuff the other day, and it wouldn't push for me at all (looked like it was, but didn't). There were a few others I found with the same problem, but no resolution.

Re: We’ve Moved CoApp code hosting to Github

Conan Kudo (ニール・ゴンパ) — Tue, 26 Apr 2011 19:58:32 -0000

You don't have to mess with msysgit if you don't want to. You can use Mercurial with the hg-git plugin (developed by github) to completely manage github repos. Especially since there's a Mercurial integration plugin for Visual Studio 2010. If you have problems with msysgit, it is a very good alternative.

Re: Binding Events to .NET 4.0 Tasks instead of Objects (Part 1)

Garrett Serack — Wed, 13 Apr 2011 17:35:14 -0000

I'm writing up part two right now!

Re: Binding Events to .NET 4.0 Tasks instead of Objects (Part 1)

Eric — Wed, 13 Apr 2011 17:24:56 -0000

Damn I actually sort of get why this is so cool now. I'm interested in learning more!

Re: Binding Events to .NET 4.0 Tasks instead of Objects (Part 1)

Garrett Serack — Wed, 13 Apr 2011 17:12:38 -0000

Yes, you are correct; the events are executed on the task's thread, but it's trivial push notifications back to the UI thread:

Similar to my last code, but using Invoke with a lambda to jump back to the UI thread.

/// this simplifies the use of Invoke with a lambda expression.
protected void Invoke(Action action) {
    base.Invoke(action);
}

public void DoSomeOperation() {
    // *** Example One *** 
    // Listening to events
    // but attaching after the task starts
    var taskOne = CoTask.Factory.StartNew(() => {
        for (var q = 10; q > 0; q--) {
            // simulate a longer running operation
            Thread.Sleep(200);

            // that occasionally notifies anyone who cares to listen.
            TestEvents.Invoke.Message1("Message From taskOne", q);
        }
    });

    // start listening to messages after the task has started. 
    ((TestEvents)taskOne).Message1 += (aString, anInt) => {
        Invoke( () => {
            // because of Invoke, this ends up back on the UI thread.
            textBox1.Text = "The Message is " + aString;
        });
    };
}

Re: Binding Events to .NET 4.0 Tasks instead of Objects (Part 1)

Gamlor — Wed, 13 Apr 2011 16:35:56 -0000

Indeed, the TPL is awesome. And when the async stuff if out, it will be even more awesome.

Just out of curiosity: I guess the events are dispatched/executed on the 'task'-thread right? I guess for GUI apps you would add a SynchronisationContext to dispatch the stuff back to the GUI thread, like the async-CTP does it.

Re: Simulating Symlinks for Windows XP/2003

Garrett Serack — Sun, 10 Apr 2011 09:57:00 -0000

I've just retested deleting a junction point on XP via explorer. It does not delete the contents.

Even if it did; the deletion of files or symlinks without using the package manager (or add/remove programs) is a foolish and insane idea, and I would have no problem telling them "don't do that" and "too bad for you" if they did.

Re: Simulating Symlinks for Windows XP/2003

Bert — Fri, 08 Apr 2011 19:59:31 -0000

I have a few remarks:

- Junction points *do* support cross-volume links. They just do not support relative paths.
- In Windows XP junctions are kinda dangerous because explorer does not understand them. If you delete a junction from explorer the files in the junction target directory get deleted as well.

Re: Simulating Symlinks for Windows XP/2003

Garrett Serack — Fri, 08 Apr 2011 08:46:21 -0000

Funny, junctions do work just fine in Explorer for me, just as I'd expect. What problems are you finding?

And really, the idea is that people generally shouldn't be deleting applications by simply removing files out of c:\program files , and they shouldn't delete out of c:\apps either... that's why we have Add/remove programs.

I'm not sure what 'interference' you're expecting.

Re: Simulating Symlinks for Windows XP/2003

Sam Moffatt — Fri, 08 Apr 2011 07:01:14 -0000

One of the problems with junction points is that explorer doesn't handle them like symlinks are handled and deleting it using any other tool will result in the original files being deleted first and then the junction point being removed.

How will you protect it from being interfered with by other applications?

Re: Simulating Symlinks for Windows XP/2003

Garrett Serack — Thu, 07 Apr 2011 13:28:36 -0000

With regards to symlinks, no absolutely no support on FAT volumes.

For CoApp V1, I'm not doing any testing on FAT systems at all; and without hardlink, symlink or junction support, CoApp packages won't install correctly to FAT volumes.

For CoApp V2 (somewhat down the road), where we aim to also support 'portable' installs of applications (by using local SxS support for shared libraries, etc), packages should be able to install into a FAT volume.

Re: Simulating Symlinks for Windows XP/2003

Jeff Hardy — Thu, 07 Apr 2011 12:15:32 -0000

What about WinXP/FAT32 systems? Not supported?

Re: CoApp in the first 90 days

Jean-Rene Roy — Mon, 05 Jul 2010 16:20:13 -0000

Hi Garrett,
I run (with others) the Ottawa UG and if you are passing by, We also like to see this presentation about CoApp.
Let me know if it's possible. Ho! your blog rocks! :)

Re: CoApp in the first 90 days

Jean-Rene Roy — Mon, 05 Jul 2010 16:20:13 -0000

Hi Garrett,
I run (with others) the Ottawa UG and if you are passing by, We also like to see this presentation about CoApp.
Let me know if it's possible. Ho! your blog rocks! :)

Re: What CoApp packages would you like to see?

karellen — Wed, 05 May 2010 20:28:21 -0000

I'd really like to see a bunch of the core FLOSS "system" and "desktop" libraries as CoApp packages. glib. gtk2. qt4. boost. cairo.

There are so many little FLOSS apps out there which provide a tiny rpm or deb for Linux, but a large installer for Windows because they need to provide their own version of, e.g. GTK2, in order for installation to be easy enough for people to bother with. If the authors of these apps could rely on CoApp packages of these core libraries being available (at least for automatic dependency resolution download, if not already installed) then this would allow/encourage them to make their own CoApp packages, which would be much smaller and more streamlined than their existing installers. As a result, I think much more software would suddenly become accessible to "normal users" under Windows.

After that, it'd be really nice to see KDE or Gnome, although I think those projects have enough manpower to make their own CoApp packages once the tech becomes available. They pretty much have Windows installers of one form or another anyway, and this is going to make things so much easier. (Not that the system libraries I mentioned previously don't have manpower, but I get the feeling that library authors are less concerned with doing their own packaging than app authors)