JobServe Labs - Articles

Recruiting on the move

2011-05-31T09:00:17+01:00

“Calling all recruiters” we need your help. JobServe has successfully been developing apps and websites targeting the Mobile platform to allow Job Seekers to search and apply for your jobs from anywhere. These have now delivered over half a million Job Applications in the 14 months they have been around.

Last year we launched JobServe Connect Headhunter – a mobile friendly website which enables recruiters, like yourself, to hunt down ideal candidates in your busy day, without having to be at your PC. We are pleased with the acceptance of this feature and many recruiters are benefiting from getting at our top candidates quickly and not missing out while you are out on meetings or travelling on a train.

It is a fact that more and more of business transactions will occur on a mobile device in the coming years and a fact that no business wants to be left behind accessing this technology. What else could be done to simplify using JobServe for your recruitment needs via your Mobile. Let us know on mobile@apps.jobserve.com

Should we target specific devices or stick with one-fits all Mobile sites such as Headhunter?

Managing your jobs on the move?

Viewing Applications to your jobs?

Messages to and from candidates?

Let us know!

mobile@apps.jobserve.com

“Please leave a message after the tone”

2011-05-31T08:49:26+01:00

We need your help. The JobServe Mobile platform has been around for a while now with our iPhone App (now on version 3.03), the iPad app and our Mobile friendly site for other mobile platforms. These have been very successful and many of you have been using them to search and apply for jobs, quickly and easily. We want these apps to be the best they can be for you and so we are planning our next phase of releases.

iPhone App Version 4.0

Apps on the iPhone continue to improve and the way features are offered becomes more intuitive and utilises the technology more and more. How could searching for a job be improved on the iPhone? Is there any features or apps you have used (not necessarily job hunting apps) which provide mechanisms or techniques that could assist you?

We have many ideas for what features we can offer in the next big release, many of these are based on feedback you have already been providing over the last few months – but, let us know of anything you think would improve your experience on the iPhone and help you chase down that next job.

Simply email us at iphone4@apps.jobserve.com

iPad App Version 2.0

We launched our iPad app the day the iPad made its grand entrance in the USA, in April 2010. Since then it has been a successful addition to our suite of mobile offerings but it lags the iPhone App on features. Instead of cloning exactly the iPhone app we want to make sure our iPad app utilises the technology the iPad can offer. That is why our iPad App was designed specifically for the device, with full screen use and not just simply an iPhone App running on the iPad.

Is there anything you have seen on the iPad that you think would enhance your experience hunting for jobs. iPad Apps provide some very immersive experiences, but applying for a job should remain simply, quick and intuitive.

Similarly to the iPhone, are there any features which you would feel are MUST HAVE for the iPad. Let us know at ipad2@apps.jobserve.com

JobServe Mobile 3.0

Our new Mobile friendly web site has provided job search and application features to thousands of candidates over the last year. Whilst not as full featured as the iPhone App it has provided some unique features such as a Job Basket. We want to continue to provide a simple interface to JobServe that allows the most availability of services to Mobile users. But what are we missing? How can the Mobile site be improved? Let us know at mobile3@apps.jobserve.com

JobServe Android App 1.0

Yes, we are planning our first, Google Android targeted App. What we need to know is What is crucial to this App being a success? Android users currently heavily use the Mobile site so what will encourage transition to the Android App. Let us know on android@apps.jobserve.com

Another update to our iPhone Job Search

2010-09-30T07:46:00+01:00

Today version 3.01 has been released, this follows very quickly on the heels of the last major release, version 3.0. JobServe Connect – Job Search app for the iPhone is proving so popular that we are inundated with feature requests and suggestions – this app is for you to find new jobs so any requests deemed useful for the majority of users is implemented.

This release contains three useful additions:

When a search for jobs is run on the results page the jobs are marked as viewed if you have recently viewed their full detail.
Also if a job has been applied for already, you will be shown this on the results.
The Date the job was posted on to JobServe is now also shown on the results page.

The other important reason we have released a new version is to also correct an issue with version 3.0 running on iOS3. The search screen did crash unpredictably, we apologise for this oversight and with this release following only one week after v3.0 was released we hope the inconvenience was minimised. Now users who have not been able to upgrade their iPhone OS to OS4 or above can benefit from the full features in v3.0 (and now v3.01)

As usual the app is available on iTunes – just search for JobServe.

Keep the suggestions coming.

iPhone Job Search Version 3.0 released

2010-09-22T14:30:00+01:00

We are pleased to announce that version 3.0 of our successful JobServe Connect – Job Search app for the iPhone has now been released.

Following feedback from our users we have added a few minor usability improvements and the following two major features:

Industry Search – You can now refine your search to a specific industry or a collection of industries from the main search screen.
Select your CV – When applying for jobs you are now able to select which CV from your online JobServe account will be attached to your application. Now you can easily store multiple CVs on your account and then send the right one to the right job.

We plan to release another update in October including some more of your ideas and also a long awaited version 2 of the iPad app will come in October.

The app is on iTunes simply search for JobServe.

JobServe Connect new addition

2010-09-16T19:07:00+01:00

There is a great need to allow job seekers and recruiters easy access to what they need to do on a Job Board from wherever they are. Smart Mobile phones are on the increase and many find internet access while out and about almost a necessity.

Applying for that great new job as soon as it is posted is a great bonus for any serious job seeker – JobServe Connect Job Search for the iPhone and iPad was the first way we gave full access to job seeking and applying from a mobile. We have seen legions of users download and use this app daily and the numbers continue to grow. In June we extended our Mobile reach by releasing the long awaited update to our mobile site – JobServe Connect Mobile. This allowed other internet enabled phones to access job seeking and applying as simply as possible.

The summer has seen record numbers of users use both mobile job seeking tools and September is no difference.

The iPhone app is approaching its 1 millionth search since version 2.0 was launched in March. Our dedicated iPad app continues to be the only fully featured, iPad designed Job Search app and has a loyal following with nearly 90,000 searches since its launch on the day iPads came into this world.

So what next for JobServe Connect?

As the name implies, we want to connect users to JobServe and eventually users to each other. The suite of tools has now ventured to recruiters, with JobServe Connect Headhunter.

Recruiters can now feel the benefit of a full candidate search tool at their fingertips no matter where they are. For Job Seekers this is a great enhancement to their chances of finding a new career as recruiters will have access to your CV (you must select your CV to be distributed for this to happen) and match you to potential roles quickly and simply.

JobServe Connect Headhunter is currently a Mobile designed website. Later in the year a dedicated iPhone/iPad app will join the suite.

Stayed tuned though as v3.0 of the Job Search app for the iPhone is about to make an appearance any day now – you can search by industry and select which CV to use in your applications – to name but two new features.

Search and Apply for Jobs from anywhere

2010-09-02T23:27:00+01:00

Jobserve Connect – Job Search is the fully functional job search and job apply application for mobile devices. We have dedicated apps for iPhone and iPad as well as the new mobile website to cover this and other devices.

Our apps are free on iTunes and are often updated. The iPhone app currently is version 2.1 and version 3.0 is due any day now, so download it today and you will get the latest update as soon as it is available.

Our iPad app remains the only dedicated iPad Job Search app and uses the full screen capabilities to display the jobs.

Key Features of the App

Automatic Search History – Saves search criteria and allows users to rerun searches with one simple click.
Search Assist – A simple 5-step wizard to help users build a quality search and remembers selections between sessions.
Store Jobs as Favourites – Allows simple collection of jobs to be emailed at a later time.
Suggested Jobs – Provides custom list of job recommendations based on previous searches and activity.
Salary Search using a two ended slider – Be as specific as you need.

JobServe iPhone App Update

2010-07-07T09:19:00+01:00

Recently Apple released the latest update to their iPhone operating system, OS4. Despite the fact that the JobServe app was designed to work with OS2.2 and above, this latest release has caused problems. We immediately tracked down the problems to two key areas – the Jobs Near Me functionality and paging between search results. It would appear that possible changes caused by the fact OS4 supports multi-tasking had caused these issues.

During this time OS3.13 or below continued to function correctly.

An update was made and submitted to Apple on June 30th. We are pleased to confirm that the fixed version is now available on the iTunes App Store and you can either download this again or await an update from the App Store on your iPhone.

During this time the iPad version of JobServe Connect continued to work correctly.

Here are quick download links:

JobServe Connect Job Search for iPhone v2.1 (OS4 Compatible)

JobServe Connect Job Search for iPad v1.0

JobServe Mobile Job Search launch

2010-06-07T22:11:00+01:00

We are pleased to announce a massive update to our Mobile website. As part of the JobServe Connect series which already has iPhone and iPad Job Search applications, we now have our newest member of this suite of products.

JobServe Mobile was first launched in 2001 and we have now updated the design and functionality so it is more in line with the apps already available for the iPhone and iPad. Now you can have full Job Search and Job Application functionality on a Blackberry, Nokia, Android based, Windows Mobile and many, many other devices.

Take it for a spin, while you sit with a coffee in one of the many coffee shops offering fast internet access and apply for your next job quickly and easily.

Quick Feature List:

Full Job Search with proximity distance option, salary search and standard sort order / days old selection.
Email jobs to your inbox – apply later.
Log in to your online profile.
Apply for jobs in as little as two clicks. If you have already answered the questions – no need to answer again.
Run any of your saved searches from your online profile.

Job hunting features at your fingertips

2010-05-04T14:05:00+01:00

Search and Apply for Jobs from the convenience of your iPhone or iPad

JobServe Connect – Job Search App is a fully functional job application system that enables users to quickly search and apply to jobs in the US. The app is available for download through the itunes store at no charge.

Key Features of the App

Automatic Search History – Saves search criteria and allows users to rerun searches with one simple click.
Search Assist – A simple 5-step wizard to help users build a quality search and remembers selections between sessions.
Store Jobs as Favorites – Allows simple collection of jobs to be emailed at a later time.
Suggested Jobs – Provides custom list of job recommendations based on previous searches and activity.
Salary Search using a two ended slider – Be as specific as you need.

Download NOW

iPad WiFi and WiFi+3G versions are available in the US, however Apple have slated a release globally from late May. The JobServe app is available in all iTunes stores and can be downloaded as soon as the iTunes iPad App Store opens in your territory.

For more information on advertising a job on JobServe and getting your job in front of thousands of active iPhone and iPad users visit here.

Search thousands of current jobs now on the Main JobServe site.

Now available on the Apple iPad

2010-04-02T23:28:00+01:00

The iPad is released tomorrow by Apple and we are pleased to announce that the popular JobServe iPhone Job Search app is now available on the iPad. All the great features you have come to expect from the latest v2 iPhone app are presented on the iPad whilst maximising usability and flexibility with the much larger screen.

If you have ordered an iPad or are one of the keen buyers to snap one up on launch day – take a look and use the new app to help find your next job.

Direct link to the App Store here.

Remember we want feedback on this and any other development by JobServe. www.yourvoice.jobserve.com is the place to talk directly to us.

JobServe Job Search iPhone App v2.0 Released

2010-03-11T18:00:00Z

The newest version of JobServe Connect – Job Search is now available on Apple iTunes.Check out the features here and download it here (this link will open iTunes)

Job Search v2.0 to be released very soon

2010-03-09T00:14:00Z

We are pleased to announce that version 2.0 of our successful Job Search iPhone app is to be released very soon. We have listened to all the feedback over the last five months and believe that the new version of the JobServe Connect – Job Search iPhone app will be even more successful. Here on JobServe Labs we would like to give you a preview of what to expect and also a few screenshots of what is to come.

This release contains a major upgrade in new features, suggested updates and fixes.

New Features

Salary search option provided using our two ended slider – be as specific as you need.
Refine your search directly from the search results screen.
Apply for jobs quickly (see below for more details)
Register on JobServe quickly and easily via your iPhone.

Link to Online Job Seeker record on JobServe

Log in to your website account.
View your latest jobs applied for.
Run any of your Saved Searches from your online account.
Get useful candidate messages from your online account.

Applying For Jobs

JobServe announces the first fully featured Job Application system to be released on the iPhone – no web pages to navigate, completely in the app. This system fully compliments the application system provided by JobServe on the website.

You will need a candidate record and a CV on your account. You can simply log in to your account via a standard web browser and upload a CV or take advantage of the AddMyCV feature – details of which are provided on the iPhone app.

Once eligible you will be able to apply for jobs in as little as two taps. If you have answered all required questions before, you can simple review and tap "Apply". However to change any answers simple review each question in our easy step by step process and then Apply.

Useful updates to existing features

Main search screen remembers options between sessions.
Search assist remembers selections between sessions.
Fields are better aligned when keyboard is shown.
Useful keyboard toolbar buttons aid navigation.
Better feedback of activity via “Please Wait” dialog.
Auto scroll results to the top when paging.

And much, much more…

Don’t delay, download the app now and get the update from Apple as soon as it is available on iTunes.

Your Voice: let your voice be heard

2010-03-02T22:28:00Z

Today we are pleased to launch the newest member of the JobServe Labs project – Your Voice.

JobServe wants to make the features, products and services available to recruiters and job seekers as useful and effective as possible. The best way to achieve this is to listen to recruiters and job seekers – so Your Voice is your opportunity to influence what we have to offer to you.

Our first release of the JobServe Connect – Job Search iPhone app generated lots of very good feedback and questions which can now be presented on Your Voice for everyone to read and join in.

Your Voice is a simple discussion and comment forum where we will start some discussions on topics but more importantly so can YOU.

Get started with the following new discussions:

Making Job Searching even better – have views on Job Search – let us know.
Come and meet “Your Voice” in London – Your Voice is at a career event but what are your views on events?

“Let your voice be heard”

We help Microsoft fix Visual 2010 Help Manager

2010-02-10T11:33:56Z

In a previous post we described a bug in the VS2010 Beta 2 MSDN product which prevents you from getting hold of help collections etc when you sit behind an Http proxy.

In that post we provided a solution which involved leveraging Fiddler’s ability to chain together proxy authentication on an application’s behalf.

We also spotted this post on MSDN Forums and posted an answer indicating a possible solution for the person who opened the issue.

As you’ll notice from the bottom post – a request was made by an employee of Microsoft to see if we could help them test a fix that they had in mind. We did; the fix didn’t work completely, but we were then able to diagnose exactly why the fix didn’t work and have subsequently discovered how to make the Beta 2 MSDN 2010 Help Library Manager without having to use Fiddler. Based on our investigation, the team at Microsoft are now working on a fix – and might already have applied it in the Release Candidate of VS2010 – which released in the last week.

Use at your own risk!

Before we go into the details, it must be stressed that this fix is not offered officially by Microsoft and therefore carries no guarantees from them. We also make no guarantees about this fix either – it will involve changing registry settings and if this turns out to break anything else on your machine, then we will accept no responsibility for that. It’s your choice to follow our directions here!

Step 1

Modify the HelpLibManager.exe.config file found in Program Files [(x86) if on a 64 bit box]\Microsoft Help\v3.0 and add the following xml inside the <configuration /> node:

<system.net>
  <defaultProxy useDefaultCredentials="true" >
  </defaultProxy>
</system.net>

Save the config file.

On its own, this fix allows the help manager to ‘see’ the collections that are available for download – but it does not actually fix the problem of the download itself.

Step 2

This is the messy bit.

Open up the Registry Editor and make sure that registry value HKLM\Software\Microsoft\Windows\CurrentVersion\BITS\UseLMCompat is set to zero (the reason why is explained in a moment). If you need to change it, you should make a note of the previous value – or better yet, create a System Restore Point.

Restart the Background Intelligent Transfer Service, and then start up the help library manager. It should all now work without any problems – assuming you have internet connectivity at all; and that your user name and password allow you through the proxy in the first place :)

Why does it work?

We ‘discovered’ that Help Library Manager uses BITS (Background Intelligent Transfer Service) to initiate and manage the actual downloads of the content. Presumably this is because the files are typically rather large. This runs in a separate process and is communicated with over a COM interface, therefore the configuration file fix has no effect on that.

After some poking and prodding, we discovered that when a BITS transfer is initiated, the caller has the opportunity to specify the credentials to be used for the network connection. Working on the basis that the code in the Help Library can’t be setting these credentials (otherwise it would work), we looked for a way to get BITS to use default credentials. The article from the last link above provides the answer to that – which yields the registry hack.

Be aware that modifying this registry value affects all software that uses BITS – and therefore it’s just possible that other things might stop working as a result.

As we mentioned earlier – we don’t know if the bug has been redressed in the RC of Visual Studio 2010 – our findings, including this fix, were submitted to Microsoft on the 27th January – so it’s possible it was too late.

Hopefully, however, it’ll be fixed by the final release date!

That’s it for now, but stay tuned: We have some very exciting news on the way in the next couple of weeks; but we’re not allowed to talk about it yet ;)

Link Tag in Content Control not created as HtmlLink

2009-11-25T12:31:46Z

The Asp.Net System.Web.UI.WebControls.HtmlHead class is clever, especially when it comes to stylesheet <link> tags in master pages, since it magically rebases them (using Control.ResolveClientUrl) to be relative to the path of the page that is executing instead of the master page. This is especially necessary when a content page is declared in a different folder to its master page, because any CSS references are unlikely to work except by pure fluke.

With the advent of Visual Studio 2008, it has become common practise to have a content placeholder in a master page’s head section, which allows the page designer to add extra meta data, script references and CSS links on a content page as well. To be fair, this process started almost as soon as master pages came into being – except Visual Studio 2005 did not have design-time support for it, a deficit that was much bemoaned by K. Scott Allen at the time.

This website uses that ability so that our master page contains our common CSS references, but some of our content pages then have their own script references and styles. In order to get around the url-rebasing issue, we use a <base /> tag at the top of every page, so that we can use root-relative links for our urls, css and javascript references, then the browser will happily get them from the correct place. A recent article detailing a fix for a small bug with the Atom Feed link on one of our pages details this process a bit more.

Now we’re working on a new site, that will be using the Asp.Net MVC 1.0 Framework (and possibly 2.0 if it goes live before we’re finished). This brings even more potential problems with relative URL links, since every page URL is actually a folder. Although the <base/> tag is a solution, it’s not perfect since you then have to define a way to actually format out that base url. Many people use configuration, but it royally sucks for this, as it means that every time you move the site to a different machine (different developer boxes, QA box, staging box etc) or from a virtual directory to a website, you have to update the configuration.

Magic URL rebasing – the good

As mentioned in the introduction, any <link> tag that is placed directly inside the Head control of an Asp.Net page will be turned into an HtmlLink control – the magic for this is done in the HtmlHeadBuilder’s GetChildControlType method:

public override Type GetChildControlType(string tagName, IDictionary attribs)
{
    if (string.Equals(tagName, "title", StringComparison.OrdinalIgnoreCase))
    {
        return typeof(HtmlTitle);
    }
    if (string.Equals(tagName, "link", StringComparison.OrdinalIgnoreCase))
    {
        return typeof(HtmlLink);
    }
    if (string.Equals(tagName, "meta", StringComparison.OrdinalIgnoreCase))
    {
        return typeof(HtmlMeta);
    }
    return null;
}

Very simple indeed. As you can see, in order to get an HtmlLink created in place of a standard <link> tag within the head, you have to do, well, nothing at all (not even make it runat=server). When the HtmlLink control renders it’s output, instead of dumbly rendering the attributes (i.e. the href, rel etc) it does this:

protected override void RenderAttributes(HtmlTextWriter writer)
{
    if (!string.IsNullOrEmpty(this.Href))
    {
        base.Attributes["href"] = base.ResolveClientUrl(this.Href);
    }
    base.RenderAttributes(writer);
}

The ResolveClientUrl method is used to calculate the actual relative path to a resource, given a template-relative path (e.g. “~/Pages/page.aspx”, “~/Controls/control.ascx”, a master page virtual path or whatever) – which is retrieved from the first control up the parent-child hierarchy of the page that has one of these paths.

Magic URL rebasing – the bad

<script> tags don’t get rebased - ever

There is one tag in particular that is missing from the logic in the above code - “script”. Yes, that’s right, whilst <link> tags will be magically rebased, <script> references will not – which is indeed a stark omission from the Asp.Net framework. From the master page point of view, this means that you cannot really have <script> references in your master page’s header, unless all content pages will be in the same relative location from the target javascript file.

This problem can be solved in a couple of different ways. The first would be to pre-process the page content before it finally gets rendered, searching for any <script> references, parsing them manually, using Control.ResolveClientUrl to get the target script reference and then writing the fixed URL back to the content (indeed, this approach has been taken with a fix adopted by one frustrated Asp.Net user; see later).

However, the other approach is to write a simple server-side control to do it:

/// <summary>
/// Mimics the HtmlLink control - i.e. calling ResolveClientUrl at render time - 
/// except it's done on the 'src' attribute value.  Since HtmlLink writes the resolved
/// path back to it's Href member, this one does the same.
/// </summary>
public class HtmlScript : HtmlGenericControl
{
  public HtmlScript() : base("script")
  {
    
  }
  public HtmlScript(string tag) : base(tag)
  {
  }
  public string Src
  {
    get
    {
      return this.Attributes["src"];
    }
    set
    {
      this.Attributes["src"] = value;
    }
  }
  protected override void RenderAttributes(HtmlTextWriter writer)
  {
    Src = ResolveClientUrl(Src);
    base.RenderAttributes(writer);
  }
}

With this in place, you simply use the <#@ Register directive, or register a site-wide prefix via the web.config, to bring in a tag-prefix (e.g. “asp2”) for the control and then, in your ASPX source you change your <script> to:

<asp2:HtmlScript src="../myscript.js" type="text/javascript" language="javascript">
</asp2:HtmlScript>

Okay, so this isn’t a perfect solution – a site-wide refactoring like this could take some time! However, the best it yet to come…

Content controls in the head – even <link>s don’t get rebased

This is possibly the biggest problem, when you use a content control to inject extra links, references or whatever into a page head section from a content form, the magic CSS <link> rebasing no longer works. Why? The clue is in the above code snippet from HtmlHeadBuilder.GetChildControlType. Consider the following master page, and content page:

Master Page <head> section:

<head runat="server">
  <title>
    <asp:ContentPlaceHolder ID="TitleContent" runat="server" />
  </title>
  <link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
  <asp:ContentPlaceHolder ID="CustomHeadContent" runat="server" />
</head>

Content Page Content Placeholder:

<asp:Content ID="customHead" ContentPlaceHolderID="CustomHeadContent" runat="server">
    <link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
</asp:Content>

Okay, so in this example, both pages are referencing the same stylesheet, so it’s slightly contrived. However, assuming that the css files are in ~/Content/, the master page is in the ~/pages/masters/ folder, and the content page is in the ~/pages/content/ folder, this will work fine when it is run.

However, if we’re using something like MVC (or using the HttpRequest.PathInfo property like we do for our articles, projects etc) in order to beautify your urls, then we will run into problems. For example, if the content page in question is actually displayed in the browser with the url “/home/”, then the CSS link rendered from the head on the master page will correctly come out as “../content/site.css”, however the CSS link from the page’s content control will be left untouched (indeed it will be rendered as a literal), and will generate a 404 when it hits the browser.

This is because in order for the <link> markup in the content control to be turned into an HtmlLink, instead of being left as raw markup, the control builder that parses the <asp:Content> control (ContentBuilderInternal – no MSDN link because it’s understandably undocumented!) would have to have the same logic in it that the head section does – since the ASP.Net build engine sees the <link> tag as a child of the Content Control, not the HtmlHead that the content eventually gets merged into.

This is clearly a bug, or at the very least an oversight, in the Asp.Net framework – and has been reported on MS Connect by Nathanael Jones, who came up with the aforementioned page-parsing solution on his blog. However, this solution does not fix design-time problems (since the VS designer doesn’t run all of the page code when rendering it in the designer), and it is also quite a weighty solution which will inevitably slow down page rendering; our sites get tens of thousands of hits per day, and adding extra load on the servers is just not an option.

Our solution

Our solution fixes rebasing of all css <link> tags in the head of content pages, and it also automatically picks up and rebases all <script> references as well. You’ll need the HtmlScript control, whose source code was presented earlier on; then add this code:

/// <summary>
/// It's a placeholder, really - it simply tells the framework to use the RebasingContainerBuilder to 
/// create the controls that will emit the html.  Then, the designer is set to ControlDesigner - 
/// the same one that the ContentControl uses.
/// That ensures design-time support for the CSS and Javascript links on content pages.
/// </summary>
[ControlBuilder(typeof(RebasingContainerBuilder)), 
  Designer("System.Web.UI.Design.ControlDesigner, System.Design, " + 
  "Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"), 
  ConstructorNeedsTag(false)]
public class RebasingContainer : HtmlGenericControl
{
  public RebasingContainer()
  {
  }
  protected override void RenderBeginTag(System.Web.UI.HtmlTextWriter writer)
  {  /*doesn't render it's own tag*/ }
  protected override void RenderEndTag(System.Web.UI.HtmlTextWriter writer)
  {/*doesn't render it's own tag*/}
}
/// <summary>
/// This class is almost identical to HtmlHeadBuilder.  It's purpose to ensure that embedded
/// links and script tags are always rebased for the client during rendering.
/// The HtmlHead control does this for CSS link tags only, and the functionality is lost 
/// on content controls on content forms.
/// This builder is used by the <see cref="RebasingContainer"/> control
/// </summary>
public class RebasingContainerBuilder : ControlBuilder
{
  public override bool AllowWhitespaceLiterals()
  {
    return false;
  }
  public override Type GetChildControlType(string tagName, System.Collections.IDictionary attribs)
  {
    /* copied this code from System.Web.UI.HtmlControls.HtmlHeadBuilder */
    if (string.Equals(tagName, "link", StringComparison.OrdinalIgnoreCase))
    {
      return typeof(HtmlLink);
    }
    if (string.Equals(tagName, "script", StringComparison.OrdinalIgnoreCase) 
        && attribs.Contains("src"))
    {
      //only rebase script tags that have a src attribute!
      return typeof(HtmlScript);
    }
    return null;
  }
}

If you’ve placed this code inside the same assembly and namespace as the aforementioned HtmlScript class, then register a tag-prefix for that assembly/namespace (as before – the best place is in the web.config so it’s available on all pages) and you can start using it.

In order for content page script and css references to get rebased you simply change this:

<asp:Content ID="indexCustomHead" ContentPlaceHolderID="CustomHeadContent" runat="server">
  <link href="/Content/TestSite.css" rel="stylesheet" type="text/css" />
  <script src="/Content/script.js" type="text/javascript" language="javascript" />
</asp:Content>

To this:

<asp:Content ID="indexCustomHead" ContentPlaceHolderID="CustomHeadContent" runat="server">
  <asp2:RebasingContainer runat="server">
    <link href="/Content/TestSite.css" rel="stylesheet" type="text/css" />
    <script src="/Content/script.js" type="text/javascript" language="javascript" />
  </asp2:RebasingContainer>
</asp:Content>

Note that the asp2: prefix here depends on what prefix you actually register with Asp.Net. At run-time and design time, the RebasingContainer control doesn’t render it’s own tags – it simply acts as a placeholder to instruct Asp.Net to delegate to RebasingContainerBuilder which, in turn, contains the logic to map <link> and <script> tags to the server side controls that will perform the magic rebasing – just like the HtmlHead control.

Similarly, you can use the rebasing container to rebase <script> tags in the master page’s <head> content (or indeed any page’s head content) – simply move all your existing script tags into a new RebasingContainer, and it will work (don’t worry about the <link> tags – since the HtmlHeadBuilder will take care of those for you).

When you first do this, the designer might get upset and tell you that it doesn’t recognise the RebasingContainer – simply do a full build, and it will update. Now flip to design view on one of your content pages that previously didn’t work and smile at the fact that any extra stylesheets are now working in design view! Notice also that inline javascript will pick up intellisense from any script references that have had to be rebased in order to be picked up.

A better, but near-impossible, solution

One solution that has been suggested by the community is to sub-class HtmlHead and it’s HtmlHeadBuilder in order to force <link> tags to be always mapped to HtmlLink controls. There are numerous problems with this, the first and most crucial is that HtmlHead is a sealed class, so that’s impossible. Even it were possible, however, it wouldn’t really help because, as explained earlier, the HtmlHeadBuilder is only used to parse the direct content of a runat=”server” <head> control, and would never actually get a chance to process the ASPX markup for a page’s Content control.

Another solution that we researched was to do a similar thing, but for the Content control; that is, sub-class the Content control and it’s associated control builder class, making it <link> and <script> aware. This would have meant simply changing the control tag used on a content page to inject content in the page’s header. The big problem with this, however, is that the Content control uses an control builder that’s internal to Asp.Net: ContentBuilderInternal, which by definition cannot be subclassed. It’s possible to call into internal classes and methods (using dynamic code generation – e.g. via Linq Expression Trees or DynamicMethod), but we didn’t have the time to build a proxy and all the code generation logic.

In the meantime, we hope that this explains the problem and provides you with an easy-to-use solution!

VS2010 Beta 2 – Fatal Error Occurred installing Help

2009-11-13T17:14:35Z

Update (10th Feb 2010) – a more thorough investigation of this issue has been carried out by us (after being asked to help Microsoft fix the problem) and a new fix is detailed here.

We’ve been playing around with the beta 2 of Visual Studio 2010 and really like the Web Install idea - although the actual VS2010 part of the download appears to be throttled at around 4Kb, which is a little frustrating!

At the very end of the installation you get to install the new MSDN Help 3 Collections, choosing online or local help as your primary source. If you’re running behind a web proxy that requires authentication you will see a “fatal error occurred” message pop up, and that’s it – there’s nothing you can do to get help on to your machine (except to get your SysAdmin to allow you out of the building without going through the proxy).

However, we have found a rather cheeky solution to this problem – the rather marvellous Fiddler Http Web Debugging Proxy.

To get it to work

Scenario 1: All you should have to do is download Fiddler, install it and run it, then hit the ‘Get Content Online’ link again. Eventually you’ll see all the content offerings, select the ones that you want and then hit the Update button.

You should see web requests in Fiddler going through to packages.mtps.microsoft.com once the transfer starts. Don’t worry if they appear to take for ages to complete – you’re watching a multi-part download, and nothing really interesting is going to happen until it’s finished!

Scenario 2: If this doesn’t work – then it’s possible you might have to force Fiddler to remember your credentials for your proxy. The best way to do this is to load a page in IE, and you should see a proxy login box appear. Enter the correct credentials for your proxy and check that the web page then loads correctly.

Now try to get the help content again – it should work.

Why does Fiddler make it work?

Here’s our theory: Obviously the Help installer client is not proxy-aware. So it attempts to make a connection to the package download location, but hits the system proxy. When this happens, the proxy returns a request for credentials, but the code isn’t written to send them over, and so it simply crashes.

The reason why fiddler makes it work is because if it receives a Proxy Authentication request (Http Status Code 407) from the upstream proxy, it responds with the identity of the user running Fiddler (Scenario 1), or a token that has previously been known to work for the current session (Scenario 2).

If that isn’t good enough, it then pushes the 407 back to the client. Now we already know that the Help Installer itself can’t cope with this, so in our Scenario 2 we use Internet Explorer to cheat, since it displays a login box when credentials are required.

IE then sends those credentials to Fiddler, which in turn are then sent to your proxy – if the proxy then lets the request out, Fiddler will cache that authentication token to be used with ALL future requests (not just those coming from IE). So when the Help Installer then makes another request, it signs that request as authenticated even though the Help Installer didn’t know it needed to.

Remote debugging code on Windows 2003 from Vista or Windows 7/2008 R2

2009-11-05T12:30:10Z

We’re in the process of upgrading our development environment from Windows Server 2003 x64 to Windows Server 2008 R2. Apart from the desktop experience being far superior, we’re also moving our web servers up to IIS 7.5, therefore we want all our web developers to be running the same. Windows 7 is of course an option for this (and it works extremely well as a web development environment – unlike Windows XP Pro), however it doesn’t offer Hyper-V, which is a must for many developers who want to run their own database servers and mock web servers.

Inevitably, however, we still have to support our existing codebase - all of which runs on Windows Server 2003. Occasionally, therefore, we need to debug something that’s running live because a problem arises that is not easy to reproduce in a model office environment. This typically means installing the Visual Studio Remote Debugger on the server that’s running the code and then attaching to it from the local Visual Studio. Many people would say that this is bad practise; in our opinion bad practise is to go the whole hog and install Visual Studio on the server machine! Remote debugging, on the other hand, is a reality of working as a developer in a technology-driven business.

The problem

Today we had to do just this, but when we tried to connect to the remote machine we got the error message "a security package specific error occurred". If you do a web search for this error, you’re likely to see this link from MSDN forums, where the user eventually solved the issue by creating a local user on both the target and local machines, and ran both VS2008 and the Remote Debugger as that account.

The solution presented is to:

Create two, administrator-level, identical local users on both the debugger machine and the debuggee machine
Run the msvsmon.exe application (the Remote Debugger binary) as that local user on the debuggee
Startup Visual Studio on the debugger machine as that local user
Attach to the debuggee

We weren’t happy with this resolution, because it points to a more fundamental problem – if Remote debugging works between two Windows 2008 R2 or Windows 7 machines, using the same VS binaries, why wouldn’t it work when talking to a Windows Server 2003 machine? Equally, we don’t want to have to go around creating local users on developer machines and servers just to get remote debugging to work. When you’ve reached this stage, it typically means that you’ve got an error you can’t reproduce any other way and you just need to ‘get it fixed quick’. Also, in a TFS environment, the Visual Studio instance in which you’re doing the debugging will not be able to connect to TFS, because the local user that you’re using is unlikely to have access to source control etc.

The root cause of this problem turns out to be slightly more subtle than the user on the aforementioned MSDN forum post assumed. It is indeed authentication that is failing, but not the authentication of the user doing the debugging against the server they wish to debug. In fact, after the remote debugging service receives a request to attach, it then authenticates back to the machine that the request originates from, and it is at this point that authentication is going wrong (we were able to generate the error that is described in that previous link by using a local account for the debugger service on the target machine but without creating it on the development machine).

Even though our service was running as a domain account which has logon rights to the development machine, for some reason the NTLM network logon token for that account that is sent back by the debugging service would appear not to work properly.

By enabling network level NTLM auditing (in Local Security Policy, enable the two settings “Network security: Restrict NTLM: Audit Incoming NTLM traffic” and “Network security: Restrict NTLM: Audit NTLM Authentication in this domain”) we were able to see the logon occur, but then the logon session is destroyed (presumably as a result of the “Security package specific error” that occurs).

A (slightly) easier solution

The good news from this is that we can offer a streamlined solution to the one provided in the above MSDN link, the bad news is that you’ll still need to create the local users:

Create the two users as before on the two machines – however, it only needs to be an administrator on the target machine.
Modify the remote debugger service on the target machine to use the new local user, start the service.
Run Visual Studio 2008 as you would normally (no need to run as the local user), and attach the debugger as normal.

Tell Microsoft!

We have logged a bug on Microsoft Connect so that the VS team can investigate the issue – if you are affected by this issue then please vote for it! At present we do not know if this also affects Visual Studio 2010 (we have a development lab set up and will investigate), if you can verify that it does, then add your experience to that bug so that we can ensure that at least the next version of VS isn’t plagued by this issue, even if it doesn’t get fixed in the current version.

Important update to iPhone Job Search

2009-10-28T22:37:47Z

A few of you had noticed that when entering a location in the iPhone App (i.e. not using the Jobs Near Me option) the numbers of results did not match similar searches on the website. Also it appeared that changing the proximity distance for these searches had no affect – in fact all searches were running “zero miles”.

Yesterday we made a change to our core web services supplying Job Search to the iPhone and we can confirm that now the proximity distance is having the desired affect.

We would like to thank those candidates alerting us to the issue – please continue to feedback to us as you can help to make this app and others in JobServe Labs more effective.

The JobServe Labs Team

Job Search iPhone App Update

2009-10-27T09:47:37Z

The JobServe Job Search iPhone App (available here) has been on the App Store for just under a week and we are very pleased with the overall reception so far. In this article we would like to discuss the feedback so far and explain some of the issues experienced.

Thank you to all the users that have taken the time to email us with constructive and useful feedback, we have had over 3,000 downloads and at least 50 emails which range from feature requests and suggestions to possible issues with the search or function of the app.

Key features requested:

Provide Salary/Rate search options
Allow user to set the number of results displayed per page
Access Saved Searches from the JobServe website
Apply for Jobs directly from the App
Display the Job Reference and recruiter Telephone number if available
Allow results to be displayed in Best Match or Posted Date Descending order

Suggested improvements to current functionality:

Change the layout of the results to fit more jobs on the screen – better use of real estate
Make the settings option more visible to users

Issues highlighted:

Jobs Near Me functionality causes app crashes for some users
Email job from Full Description screen fails

So we have a good set of request and suggestions already. Currently under review by Apple is a new version v1.01 which will provide new features 2 and 5 above. Cosmetic changes to the layout will display more jobs per page and the settings option is more visible.

In terms of bugs all should be fixed in this new release.

Jobs Near Me – This uses the iPhone API CLLocationManager class and for many users when selected this class returns the location co-ordinates quickly and accurately. However some users experience when in certain locations that this crashes – we have many reports of the same user using the app successfully in different locations but crashing in other locations. Under all testing scenarios we did not experience this, and although not a perfect excuse, we released this with belief that the required precautions were taken. On closer analysis it appears that the CLLocationManager may be returning two results very quickly – even though we have requested specifically to stop updating the location. Users experiencing the crashing sometimes saw results very quickly or just bombed out on the first screen. Users could then use the Location box for searching instead as a workaround.

The new release will be out as soon as possible and we value your continued feedback.

Following this release we will be planning another release which will contain Sort Order options and Salary Searching.

We are also working on the Application platform which will allow users to apply for jobs directly from their phone using our Job Application process similar to the JobServe website. The only requirement will be to have a JobServe candidate record and maintain a CV on the website.

JobServe Connect – Job Search for the iPhone released

2009-10-21T15:21:02+01:00

We are happy to report that the JobServe iPhone app “JobServe Connect – Job Search” has now been approved by Apple and is available from the App Store on iTunes. We thank all the users that pre-registered for the app and you should all have received your launch link to download the App.

So far response has been very good and we encourage even more of you to send us emails with suggestions and general feedback, we’ll post details of what features will be making the next release as soon as we can.

If you would like to get the iPhone app now please use this link to download from iTunes