GISbiz

Setup Visual Studio 2010 Remote Debugging – Step by Step

Every Visual Studio developer has probably come across the need of Remote Debugging at some point during development. I too faced that situation, and found only a few (not entirely helpful) references via Google.

Since I’ve spent the last few days on this issue, and Remote Debugging now works in my environment, I thought it best to document the process. Here’s a step-by-step approach to help someone in need.

Steps to enable remote debugging on a local machine:

1. Create a local user account with administrator privileges. (e.g. rmdbgr/pwd123)
2. Share the web application directory (e.g. Foo.Bar) with full control as accessible from the remote machine.
3. Enable the custom web server option in web application properties (which is below “Web” tab).

Steps to enable remote debugging on a remote machine:

1. Setup the required development environment. (IIS, .NET Framework, ASP.NET, etc.)
2. Install the Microsoft Visual Studio 2010 Remote Debugger.
3. Create an administrator user account on the remote machine with the same username and password. (e.g. rmdbgr/pwd123)
4. Go to services.msc and start the “Visual Studio 10 Remote Debugger” service with rmdbgr user.
5. Create an IIS7 virtual directory for the shared web application which is in the local machine.

Start remote debugging:

1. Run the VS2010 IDE on the local machine as rmdbgr user.
2. Open the solution and run the project in debug mode.

Possible issues and troubleshooting:

• If the “The network BIOS command limit has been reached.” error arises, check out this article: http://support.microsoft.com/kb/810886
• If any security error arises, try disabling the firewall on both machines and try again.

Where is Microsoft.Expression.Interactions?

Is your project missing a reference to Microsoft.Expression.Interactions or System.Windows.Interactivity?

Download and install the Microsoft Expression Blend SDK for Silverlight 4. It’s in there.

10 Usability Principles to guide you through the Web Design Maze

1. Motivate: Design your site to meet specific user needs and goals. Use motivators to draw different user “personae” into specific parts of your site.

2. User task flow: Who are your users? What are their tasks and online environment? For a site to be usable, page flow must match workflow.

3. Architecture – it’s 80% of usability, Build an efficient navigational structure. Remember – if they can’t find it in 3 clicks, they’re gone.

4. Affordance means obvious: Make controls understandable. Avoid confusion between emblems, banners, and buttons.

5. Replicate: Why reinvent the wheel? Use ergonomically designed templates for the most common 8-12 pages.

6. Usability test along the way: Test early in design using low-fidelity prototypes. Don’t wait until the end when it’s too late. Know the technology limitations Identify and optimize for target browsers and user hardware. Test HTML, JavaScript, etc. for compatibility.

7. Know the technology limitations: Identify and optimize for target browsers and user hardware.Test HTML, JavaScript, etc for compatibility.

8. Know user tolerances: Users are impatient. Design for a 2-10 second maximum download. Reuse header graphics so they can load from cache. Avoid excessive scrolling.

9. Multimedia – be discriminating: Good animation attracts attention to specific information, then stops. Too much movement distracts, slowing reading and comprehension.

10. Use a stats package: Monitor traffic through your site. Which pages offend user interest? Which pages make users leave? Adjust your site accordingly.

The usability guru Jakob Nielsen’s article on acceptable web application response times.

The basic advice about response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

•0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

•1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

•10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to do other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

http://www.useit.com/papers/responsetime.html

Xcode 4 Installed – Okay, How do you start it?

Quick tip:

When you installed Xcode 4, you might have expected it to show up in the Places > Applications folder. It doesn’t – At least not by default.

Xcode is installed in Devices > Macintosh HD > Developer > Applications … assuming that your main partition is named “Macintosh HD” and you accepted the default installation parameters.

read more

Read/Write a List of Strings to App.Config

There is more than one way to read and write a list of strings in App.Config or Web.Config.

read more

Readable Field Names in the ArcGIS Viewer for Flex Edit Widget

You might have noticed that the ArcGIS Viewer for Flex Edit Widget does not have configuration options for field labels, and so, by default you will get something like this:

ALTERNATE_NAME, ALTERNATE_NO, CREATED_ON, PROJECT_ID, and PROJECT_STAGE are not exactly readable, but how do you change them?

read more