Wednesday, June 10, 2015

ELMAH filtering of exceptions by type using the is-type assertion

PROBLEM: In one of our projects, validation errors are thrown as exceptions (ValidationException) - we obviously don't want to be notified about a user forgetting a mandatory field etc, and luckily ELMAH has support to filter out certain exceptions from being logged and/or emailed.  Have a read here: https://code.google.com/p/elmah/wiki/ErrorFiltering and here https://code.google.com/p/elmah/wiki/ErrorFilterExamples and here http://www.diaryofaninja.com/blog/2011/09/20/adding-filters-to-your-elmah-installation

I tried the following in the web.config and it resulted in a runtime error:

<errorFilter>
  <test>
    <is-type binding="BaseException" type="MyProject.Models.ValidationException" />
  </test>
</errorFilter>

SOLUTION:
You need to include the assembly name e.g.

<errorFilter>
  <test>
    <is-type binding="BaseException" type="MyProject.Models.ValidationException, MyProject" />
  </test>
</errorFilter>

(this isn't in the limited doco of ELMAH but the creator of ELMAH does mention it in a random forum post i.e. "In the type attribute of the is-type element, you forgot to specify the assembly where the CustomLibrary.CustomException type can be found. In absence of the assembly specification, ELMAH looks for the type in its own assembly. If your assembly name is the same as the namespace (i.e. CustomLibrary) then try changing the is-type element to read as follows: <is-type binding="Exception" type="CustomLibrary.CustomException, CustomLibrary" />"

Monday, May 25, 2015

Azure Scheduler - Job Schedule Starting On value explained

PROBLEM: For me it wasn't clear what value the Azure Scheduler - Job Schedule "Starting On" value was meant to represent (there is a list of times AM and PM and list of UTC offsets). I wasn't sure if I was meant to be entering the GMT (UTC) value for when I wanted my job to run or the local time I wanted the job to run (it's obvious after you do it). (if you just want general info on Azure Scheduler hit this link: http://azure.microsoft.com/en-us/documentation/articles/scheduler-get-started-portal/#create-a-job-collection-and-a-job)

SOLUTION: Short answer, it is the local time. When creating a new scheduled job, the job schedule "Starting On" value is the local date/time you want the job to run, to which you apply the relevant UTC offset based on the time zone of the local area e.g. If I want a job to execute at 8.30pm AEST (Australian Eastern Standard Time i.e. not daylight savings), I'd set the date to the date I want and the time to 8.30 PM and the UTC drop down list to UTC 10:00 (i.e. the time is not a GMT/UTC time, it is the local time zone you're interested in, reflected by the UTC offset value).

When you click Save, Azure will then convert this to a GMT (UTC - go here if you want the technical difference between the two http://www.timeanddate.com/time/gmt-utc-time.html) value e.g. 2015-05-25 8:30 PM UTC 10:00 will display as Mon, 25 May 2015 10:30:00 GMT (you'll no longer see the local time and UTC offset that you originally entered, this confused me a bit when looking at other schedules that others had set up).

NOTE: The big gotcha is that all that is saved is a GMT time, not a time zone - this means you'll potentially need to update your schedule for daylight savings.
http://codeofmatt.com/2013/11/04/windows-azure-scheduler/
https://blogs.endjin.com/2015/04/azure-automation-scheduler-and-daylight-saving-time/

Vote on this improvement/fix here:
http://feedback.azure.com/forums/246290-azure-automation/suggestions/6621981-fix-the-scheduler-to-be-aware-of-daylight-saving

Friday, March 6, 2015

“GatherAllFilesToPublish” Error in VS2010 Project Upgraded to VS2012

PROBLEM: After upgrading a VS2010 web forms project to VS2012, when I went to publish the project I received this error "The target "GatherAllFilesToPublish" does not exist in the project.".

SOLUTION: For me I simply unloaded the project, edited the project file to change this line:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

to this:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

After saving and reloading the project file the upgrade wizard automagically kicked in and did some magic and the publish started working.  

Aftewards I went in and had a look at the project file again and it seemed the upgrade wizard added a PropertyGroup element with VisualStudioVersion and VSToolsParth sub-elements (similar to what this guy recommended manually adding but for me manually adding them didn't work - <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />)

You'll also find lots of links about renaming Microsoft.WebApplication.targets and running a repair (http://stackoverflow.com/questions/10989051/why-do-i-get-the-error-the-target-gatherallfilestopublish-does-not-exist) - which I tried but this didn't fix the issue.

Wednesday, March 4, 2015

Cannot merge branches due to "incompatible pending change" error

PROBLEM: Merging two branches in TFS2012 and it fails saying there are 0 errors but X warnings - refer to Output window for details. When you check the Output window you see:

"TF203015: The item $/XXX/YYY has an incompatible pending change"

SOLUTION: In my case, it was because the file in the changeset I wanted to merge (web.config) had pending changes in the target branch which had been added to "Excluded Changes".  In my case I moved the file to "Included Changes" and Checked In the changeset (so the server knew). Then I was able to merge my two branches.  I think if I had discarded my changes on the target branch for that file it would have potentially resulted in the same effect.  Some other googling showed that sometimes people had this issue due to file permissions but that wasn't the issue in my case. That's a few hours of my life I'll never get back!