The zip file containing your deployment may have been corrupted, or your Reference Hint Paths are wrong

by Jon 6. October 2010 15:53

So you zip up your package, and you download it to your customers site to install onto there server and you get the following error:

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file

Exception Details: System.Secuity.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=, Culture=neutral

Your deployment may have been corrupted

You know nothing has changed the system works find on your test server, your laptop and everywhere else its just broken here, and nothing major has changed since the last release!  What can be wrong? One of two things:

Your dll references and Hint Paths could be wrong, open up your Project files and look for incorrect hint paths causing your solution to be compiled with a range or dlls causing your very own dll hell.  Or alternatively your zip and dlls could have been corrupted in some way, either way its not good.

Hopefully this post will help you find the root of your problems, the obscure error means your installation is corrupted in some way..




Automatic CI Versioning using TeamCity and MSBuild

by Jon 4. October 2010 20:33

If you read my first post on getting started with TeamCity, and my follow up post on moving to MSBuild you will have a lovely CI system that builds your solution each you commit your changes.  Whilst this sounds fantastic, unfortunately of the assemblies that are built will all be versioned with the same version that is pulled from the AssemblyInfo.  Luckily it isn't a major change to get MSBuild to update your solution files with the version number stored in TeamCity every time a build occurs by tweaking your MsBuild File: (and installing MsBuild Community Tasks)

<?xml version="1.0" encoding="utf-8" ?> 
<Project  DefaultTargets="ReleaseBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

    <Target Name="ReleaseBuild">

        <Message Text="Set the correct $(BUILD_NUMBER)" /> 
	<FileUpdate Files='AssemblyInfo.vb' 
	  ReplacementText='Version("$(BUILD_NUMBER)")' />

	<FileUpdate Files='AssemblyInfo.cs' 
	  ReplacementText='Version("$(BUILD_NUMBER)")' />

        <Message Text="Building"/> 
        <MSBuild Projects="ProjectName.sln" Targets="Rebuild" /> 



Shared Solution Level Assembly InfoThis change uses the FileUpdate Task in MsBuild Community Tasks to be performed on the two specified files, AssemblyInfo.vb and AssemblyInfo.cs.  The Regex will search for the word Version, followed by a valid four digit string version, and replace it with the build version configured in team city.

I use a Solution wide AssemblyInfo file called SolutionAssemblyInfo.vb or SolutionAssemblyInfo.cs to standardise Assembly Information across the solution by using a single shared file.  You can Create this shared file in Visual Studio by Adding a New Item to the Solution Directly, and then after you have created it you link it into each project by clicking on Add existing in each project and pressing the Arrow on the 'Add' Button and selecting 'Add as Link' instead.  This Shared Solution wide file contains the assembly info that is shared across the assemblies, each project will contain the link to shared assembly info file, and the existing assembly info file in the My Project folder.

Tags: , ,

ddd | development | MSSQL Server | Versioning


The Easy Way to fix Server Collation in MS SQL Server

by Jon 27. September 2010 21:11

When you have different developers, customers and databases your database collation is bound to get out of sync.  Making sure you have matching collation is important because it can cause problems when it comes to running SQL queries and can impact performance if you are joining text fields.  There isn't an easy way to change the collation across an entire server because the collation is stored against the fields in each table.  I looked at a number of different scripts but found the following script was the easiest way to fix the problem.  Simply set @toCollation to the collation you want in your database, and run the query.  The query will output a List of ALTER COLUMN SQL Queries which you can copy into a query window and execute to fix your database.

declare  @toCollation sysname 

SET    @toCollation = 'Latin1_General_CI_AS' --  Database default collate


       '   ALTER COLUMN ' + COLUMN_NAME + ' ' + DATA_TYPE +


            WHEN DATA_TYPE in ('text','ntext') then ''




       +' COLLATE ' + @toCollation+ ' ' + CASE IS_NULLABLE

                                           WHEN 'YES' THEN 'NULL'

                                           WHEN 'No' THEN 'NOT NULL' 





WHERE DATA_TYPE IN ('varchar' ,'char','nvarchar','nchar','text','ntext')


 and COLLATION_NAME <> @toCollation

You will find most of the queries will work, for the queries that dont work due relational joins you can open the table in enterprise manager in design mode and fix the small number of remaining offending fields manually really quickly.  Within moments you have a database with matching collation accross all its tables.


Tags: , ,

SQL | MSSQL Server


The Asp.Net Vulnerability and DotNetBlogEngine.Net

by Jon 20. September 2010 21:34


Looking at ScottGu's Post and DotNetBlogEngine.Net configuration it looks like DotNetBlogEngine may be one of the Web applications that is vulnerable in the out of the box configuration (I'm not 100% sure and I cant find anyone on the dotnetblogengine forums about it).  Its still not especially clear but it looks like we need to take these steps to take to secure our blogs.  Better safe than sorry, until the underlying problem is fixed?

Replace the Custom Errors in Web.Config

<customErrors mode="RemoteOnly" defaultRedirect="~/error404.aspx" />
   <error statusCode="404" redirect="error404.aspx" />


<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/fail.aspx" />


Then Add a new File Called fail.aspx to the root folder:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
   void Page_Load() {
      byte[] delay = new byte[1];
      RandomNumberGenerator prng = new RNGCryptoServiceProvider();

      IDisposable disposable = prng as IDisposable;
      if (disposable != null) { disposable.Dispose(); }

<head runat="server">
        An error occurred while processing your request.

For more information on the Problem and details of the fix please look at scott's post

Tags: , ,

asp.net | BlogEngine | scottgu


Could not load file or assembly <AssemblyName> or one of its dependencies. An attempt was made to load a program with an incorrect format

by Jon 16. September 2010 22:00

One of the recurring problems I get when installing our ASP.Net system onto customers servers is this cryptic error:

Could not load file or assembly <AssemblyName> or one of its dependencies.  An attempt was made to load a program with an incorrect format


The first time I saw it it really stumped me for a couple of hours to find what the problem was, the stack trace, nothing made any sence.  I eventually tracked the only difference down to the server being 64bit.  IIS can run an asp.net application in either 64 or 32bit mode and most people leave both 32bit and 64bit support enabled when they compile there ASP.Net to automatically give them improved performance on a 64bit machine.  Unfortunatly if you are using a 3rd party componant that is older, perhaps an old non managed library it is more likely to be compiled for 32bit exclusivly.  This 3rd party library means your entire application wont be able to run in 32bit mode, and to make matters worse IIS running under 64bit has 32bit support disabled by default and your Compiled code will attempt to run in 64bits, which in turn causes the nasty error message above.

There are one of two solutions:

1. find the offending library and remove it from your Web Application

2. Enable 32bit support in IIS.  

a. Go to Application Pools in IIS
b. Right click on the relevant application pool
c. Press advanced settings
d. Set Enable 32-Bit Applications to True
e. Restart the Application Pool

This quick fix will buy you time so you can remove the offending library at your leisure

Tags: , , ,

asp.net | development | IIS | TechSupport

Powered by BlogEngine.NET
Original Design by Laptop Geek, Adapted by onesoft, and finally some tiny tweaks by JonAlb