Because PostSharp 2 not announced yet, not available PostSharp installer for Visual Studio 2010. I found a blog entry which contains the instructions for using PostSharp without installing via MSI but it not works on VS 2010.

The first problem was the NullPointerException while building with PostSharp. After I googled that I found something useful. This is a known problem by PostSharp’s developers and the solution is the modify project file:

<PropertyGroup>
  <PostSharpUseCommandLine>true</PostSharpUseCommandLine>
</PropertyGroup>

There is a possible memory leak in PostSharp execution and the "PostSharUseCommandLine=True" forces PostSharp to use command-line utility. "A new process will be created for each invocation, so there can be surely be no memory leak in this time."

The second was that the PostSharp compiler does not work with .NET 4 assemblies at this moment (PostSharp 1.5). So you will downgrade your PostSharp enabled projects .NET version to 3.5. :(

The modified C# project file:

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>10.0.20506</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{AE544EFB-2842-4A41-BF6C-3038D2046E90}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>Bes.Core</RootNamespace>
    <AssemblyName>Bes.Core</AssemblyName>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
...
  <PropertyGroup>
    <PostSharpUseCommandLine>True</PostSharpUseCommandLine>
    <DontImportPostSharp>True</DontImportPostSharp>
    <PostSharpDirectory>..\..\libs\PostSharp</PostSharpDirectory>
  </PropertyGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Import Project="$(PostSharpDirectory)\PostSharp-1.5.targets" />

Sokáig kutattam egy listát a .NET-ben használható nyelv-országkódokról. Itt egy teljes lista. Itt pedig egy csomó zászló. :) Érdekes, hogy nem mindegyik kód követi a 2 betű nyelvi kód - 2 betű országkód formát:

Az ilyen jellegű hibák akkor fordulhatnak elő, amikor egy SQL Server 2008-ból update-lt edmx-et SQL Server 2005 alatt próbálunk meg használni. A megoldás az edmx file-ban a ProviderManifestToken="2008" átírása ProviderManifestToken="2005"-re:

<Schema Namespace="Bes.Services.FuckinRich.Dsl.Classes.Store" Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2008" xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" xmlns="http://schemas.microsoft.com/ado/2006/04/edm/ssdl">

A mai napomat azzal töltöttem, hogy egy éles; az internet felé is nyitott szerverre; publikáltam WCF szolgáltatásokat. Nem akartam erre ennyi időt szánni, de sikerült vele az egész napomat elrontanom.

Alapvetően 3 témakör köré csoportosíthatók az előjött problémák:

1.: ServiceHostFactory elszállás

"This collection already contains an address with scheme http.  There can be at most one address per scheme in this collection.
Parameter name: item"

A probléma itt a már jó előre beboldozott (szép magyar szó ) és aláhúzott "is" szócskában keresendő. Mint kiderült a WCF alapból nem tud több binding-ot kezelni ugyanazzal a protokollal. És hát ritkán van egy címe egy internet és a belső háló felé nyitott gépnek (pl.: http://bes és http://www.besystems.hu). Külön köszönet az MS-nek a semmitmondó hibaüzenetért. De legalább nem lokalizálva (magyarul) írta ki. :)
 
MSDN link

2 .: "The communication object cannot be used because it is in the Faulted state"

Őt régi ismerősként üdvözölhettem. Kb. a javascript-es "A várt elem objektum" hibaüzenettel egy kategóriájú "nesze semmi, fogd meg jól" jellegű szemétparaszt hibaüzenet. Mivel ilyenkor az exception csak egy ennél is semmitmondóbb stack trace-t tartalmaz, nincs más lehetőség mint bevetni a wcf tracing-et. Ebből és jó sok guglizásból kiderült, hogy valószínűleg a tűzfal vagy a router megfogja a kéréseket. Nos, mindkettő :). Ez az én bűnöm volt.

3.: WCF biztonsági beállítások

Ebben az esetben egy TCP szolgáltatásról volt szó, amely gond nélkül ment mindenféle biztonsági beállítások nélkül local-ban, kívülről viszont úgy eldobta a kapcsolatokat, hogy öröm volt nézni (mármint annak aki élvezi az ilyesmit). Persze ez így korrekt, de azért szerettem volna kipróbálni, hogy ettől eltekintve megy-e a szervizem kívülről is. A megoldás a "binding.Security.Mode = SecurityMode.None"-ra állítása volt a nagykönyv szerint. De ha ennek ellenére a dolog nem megy (ami szinte kizárt),  és kapunk egy "Net Framing upgrade request for application/negotiate was sent to a service that is not setup to receive upgrades." hibaüzenetet a WCF trace log-ban, bátran használjuk kliens és szerveroldalon egyaránt a "binding.Security.Message.ClientCredentialType = MessageCredentialType.None"-t vagy ennek az app/web.config-os megfelelőjét.