An error occurred while parsing EntityName

 PROBLEM: Received the below error at runtime:

Server Error in '/' Application.

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: An error occurred while parsing EntityName. Line 86, position 346.

Source Error:

Source File: C:\Dev\mywebsite\web.config    Line: 86

SOLUTION: Pretty straight forward case of an XML element that needed replacing in my web.config file https://stackoverflow.com/a/23542105/1450351 - in my case it was ampersand in a URL, so replaced with &  ... BUT what wasn't simple was that this was that to handle local secrets and prevent them going into source control we use:

<appSettings file="Web.secrets.config">

(This approach is taken from https://www.hanselman.com/blog/best-practices-for-private-config-data-and-connection-strings-in-configuration-in-aspnet-and-azure and https://stackoverflow.com/a/60961168/1450351 (we did consider using SlowCheetah but it is only appropriate for app.config files e.g. with console apps))

...the complication this causes is that the error message refers to web.config but the problem was actually in web.secrets.config ... so when I looked at line 86 in the web.config I couldn't see an issue - and even when I deleted line 86 the issue still remained - because it was referring to line 86 of the web.secrets.config file (the two files kind of merge at run time, with any app settings in the secrets file overriding anything that exists in web.config).

Anyway, luckily I checked the secrets file and saw the issue.

INTERESTING SIDE NOTE: Because I like being able to quickly copy and paste passwords (yes ideally we should be using Azure Key Vault or similar), when I'm creating new passwords I'll explicitly avoid certain characters which needs replacing or escaping in web.config files or other places.  So I opt for a really long password that uses only a subset of special characters e.g. $ # % -

Could not load file or assembly or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

PROBLEM: Received the below error at runtime:

{"Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"}

SOLUTION: Lots of potential answers here: http://stackoverflow.com/questions/22507189/could-not-load-file-or-assembly-newtonsoft-json-version-4-5-0-0-culture-neutr

But for me the problem was I had a solution with multiple projects, each with different versions of the nuget package. Obviously only one version can be deployed and if it an old version that gets deployed a binding redirect isn't going to help - so in my case I had to upgrade each project to use the same version of the nuget package - note there is a new feature (which I didn't use) that can help manage one nuget package across multiple projects in a solution (https://artczernecki.wordpress.com/2015/09/08/consolidating-package-versions-with-visual-studio-2015-nuget-package-manager/ and http://stackoverflow.com/questions/34022454/nuget-consolidate-vs-update).

Note, this problem reared its head again briefly after I pulled a different branch via github... I think in that case it was an issue with Visual Studio cache files (*ResolveAssemblyReference.cache) found in the obj folder of the projects... closing the solution and re-starting Visual Studio was enough to refresh these and fix the issue.

INTERESTING SIDE NOTE: Nuget package versions are not necessarily the same as the dll AssemblyVersion (the important version - this is what the compiler cares about and is the version number that is important for binding redirects etc - can view in Visual Studio under properties where it is referenced or can use ILSpy or similar) or AssemblyFileVersion (what you see when you right click and view a DLLs properties in explorer - compiler never refers to this).  As an example... Newtonsoft.json nuget package 5.0.2 has a AssemblyVersion 4.5.0.0 and AssemblyFileVersion 5.0.2.16008 ... some more reading is here: http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin and http://stackoverflow.com/questions/11965924/nuspec-version-attribute-vs-assembly-version

HTTP Error 404.17 when running WCF service in Visual Studio 2015 (VS2015)

PROBLEM: On Windows 7 with Visual Studio 2012 I could run an asp.net .NET 3.5 project with WCF services.  After installing Windows 10 and Visual Studio 2015, I could no longer debug a WCF service which previously ran fine on Windows 7 and Visual Studio 2012.  I get the following error: "

HTTP Error 404.17 - Not Found - The requested content appears to be script and will not be served by the static file handler. - Most likely causes: The request matched a wildcard mime map. The request is mapped to the static file handler. If there were different pre-conditions, the request will map to a different handler. Things you can try: If you want to serve this content as a static file, add an explicit MIME map."

SOLUTION: I had to turn on a number of Windows features that aren't on by default:

• .NET Framework 3.5 (includes .NET 2.0 and 3.0) > Windows Communication Foundation HTTP Activation
• .NET Framework 3.5 (includes .NET 2.0 and 3.0) > Windows Communication Foundation Non-HTTP Activation
• .NET Framework 4.6 Advanced Services > WCF Services > HTTP Activation (probably not required for my project but useful for the future)

I also ran this but I don't think I needed to / should have (http://ngeor.net/2011/07/iis-7-gives-404-17-error-with-svc-wcf-services/):

"%WINDIR%\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" –r

And then despite all this things didn't work, I had to manually update the IIS Express settings used by Visual Studio... WHICH are hidden away in a hidden folder in your solution e.g.

[PROJECT FOLDER]\.vs\config\applicationhost.config

I had to add the following to the section starting with <handlers accessPolicy="Read, Script">

<add name="xoml-64-ISAPI-2.0" path="*.xoml" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
<add name="rules-64-ISAPI-2.0" path="*.rules" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
<add name="svc-ISAPI-2.0-64" path="*.svc" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
<add name="xoml-ISAPI-2.0" path="*.xoml" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
<add name="rules-ISAPI-2.0" path="*.rules" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
<add name="svc-ISAPI-2.0" path="*.svc" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
<add name="xoml-Integrated" path="*.xoml" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="rules-Integrated" path="*.rules" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />

There are lots of other similar applicationhost.config files but this is the one you need to update.

I thought that because of our source control branching approach that I'd need to manually update this anytime I create a new branch that needs WCF working BUT apparently there is a project file (not web.config) setting: UseGlobalApplicationHostFile, which you can set to true to just use the global setting (which is stored in Documents\IISExpress\config) http://stackoverflow.com/questions/32940080/visual-studio-2015-debugger-uses-local-applicationhost-config-instead-of-global and http://stackoverflow.com/questions/12946476/where-is-the-iis-express-configuration-metabase-file-found (that being said, I created a new branch the other day and hadn't yet set that setting or updated the Visual Studio applicationhost.config file and I was still able to debug the WCF services... go figure!

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" />"

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

“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.

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!