Kevin Cunningham

XBox 360 bundles

kcunningham — Thu, 25 Aug 2005 05:27:00 GMT

This is a semi-non technical post :)

Ok, this is a sign of the times. Gamestop is taking pre-orders for a couple different Xbox 360 bundles ranging from $699-$1199 ... yes, that's right $1199 for the ultimate bundle. Granted you get tons of games in the $1199 bundle but WOW, that's some serious cash. Now what age range would this bundle be targeting ..... Hmmmm.

Microsoft revealed their pricing models (good read if you thinkin' about it) recently and the grumblings are already starting. Chief XNA architect, J Allerd's defends the pricing.

Quick Break down:

Xbox 360 Core System - $299 (For Existing Users)
•Xbox 360 console
•Wired controller
•Detachable faceplate
•Xbox Live Silver membership
•Standard AV cables

Xbox 360 - $399
•Xbox 360 console
•20GB detachable hard drive
•Wireless controller
•Wireless Xbox Live headset
•High-definition AV cables
•Ethernet cable
•Xbox 360 Media Remote Control (limited time)
•Detachable faceplate
•Xbox Live Silver membership

The first gaming system my family ever had was the Bally Arcade System. It used a Fairchild F8, which had 64 bytes of RAM and 2K of ROM - w00t!

I am for sure getting an XBox this time around ;) This unit may be enough to pull me away from CS:Source and BF2.

ASP.NET 2.0 Web Page and User Control access using stubs

kcunningham — Thu, 11 Aug 2005 02:21:00 GMT

K. Scott Allen has a great post on using stubs in your "App_Code" classes to access your web pages and user controls. More than likely you will encounter this situation in your ASP.NET 2.0 development days.

ASP.NET Beta 2 web sites, SCCS and Cloaking

kcunningham — Thu, 05 May 2005 03:46:00 GMT

With Beta 2 having a go-live license, more and more people are writing code that may end up in a production environment. This means that the code being written is more than likely source code control worthy. Keeping this in mind, there's a little gotcha when integrating VS.NET 2K5 Beta 2 with your source code control system (SCCS) that can make team development a pain.

With VS.NET 2K5 there are no longer web project files when using file-based web sites. The values that used to be stored in the .xxproj file in previous versions of VS.NET have now been pushed into the solution file creating a "Directory Based Project System Model". Since there is no longer a project file, there's no way to "tell" the SCCS to exclude specific files or folders within the web site. To VS.NET 2K5, everything underneath the web directory is "fair game" and is published to the web and SCCS. Matter of fact, the "Exclude from Project" context menu does not even exist. Therein lies the issue. When you add external references, e.g. ref your business layer from your website, VS.NET 2K5 places the referenced assembly in the \bin sub-folder. When you goto check in your source code, your SCCS will attempt to check in your "\bin" folder along with all of your referenced assemblies. Ooooooops! If you are using project references you know what that means, the referenced assembly gets rebuilt and the new version gets copied to your website's \bin folder during each build.

If those files are under source control how can a team work concurrently (assuming that your team uses exclusive locks)?

The short-term Beta 2 workaround is to check-in your bin folder (recursively) to your SCCS, make all of your websites' \bin directories writable locally (recursively) and to "Cloak" the "\bin" folders withing your SCCS. The reason for checking in the \bin folder is more a "give-up" instead of trying to have all of your developers remember to try and not check in the files. Both Vault and VSS support the "Cloaking" feature. I am not sure about CVS and Subversion. By cloaking the folder, Vault/VSS will not retrieve files from the cloaked location using the client utilities (i.e. not the IDE). This is really more useful when building initial folder structure or you are the habit of "Getting Latest" using the client tools provided by Vault and/or VSS. Pulling cloaked folders from the IDE ends up behaving a little differently than you would think. The SCCS providers do not obey the cloaking settings and when you "Get Latest" VS.NET will attempt to retrieve the latest files. I assume (and guessing) this is because its not a feature that all SCCS system have. Enough of the cloaked files, let's get onto the local, writable files in the \bin folder. Vault out-of-box handles local, writable files differently than VSS. Vault will attempt to automatically merge any files changes and if it can, it will fall back to a "Do Not Overwrite" behavior and you must resolve the conflict later. In the case where the reference assembly differs from the assembly in Vault, you will not be prompted and your IDE experience is unscathed. VSS out-of-the-box will prompt you that the file has changed and give you the option to overwrite you local copy or retrieve the one from the server. So the Vault experience is less-intrusive than VSS. But, this will only happen if you do a recursive get. Otherwise, setting your \bin folders to writable should give you a pretty decent dev experience.

Good thing is that others have run across this issue and someone has already posted it on the product feedback site a couple days ago. The purpose of this post is to save you some time if you run across this.

To “Cloak” in Vault (VSS is almost identical):

Open Vault Client
Right click on the \bin folders of the web sites and select properties.
Check the “This project is cloaked for me”

If someone is aware of a way to "tell" VS.NET through the solution file to exclude files for a web site in Beta 2 I would love to know?

Ahhhh ... Different Levels of Accessibility on Property Accessors

kcunningham — Fri, 29 Apr 2005 19:02:00 GMT

Today I had the opportunity to take advantage of a .NET 2.0 little gem that allows you to set different accessibility levels on your property getters/setters. I got so used to doing work arounds in 1.1 that I almost didn't use it. Ahhh ... the little things :-)

public int MyValue
{
get { return _myValue; }

protected set { _myValue = value;}
}

PS. This can also be done for indexers.

Back into Blogosphere!

kcunningham — Tue, 19 Apr 2005 03:23:00 GMT

It's been a while but I'm finally back to blogging. Since my last blog (note: that blog is no longer monitored), I changed jobs to take on new challenges at »telligentsystems. Much love to my former employer, Software Architects. They put up with me for for the past 6 1/2 years - straight outta college :^o

More to come ...