ASP.NET MVC Windows Authentication redirecionando pro login

9/25/2012 10:29:23 PM By Felipe Pessoto

Esse problema aconteceu em um novo projeto que estou trabalhando na Athié, em ASP.NET MVC 4, mas deve acontecer no 3 também, já que acredito ser um problema no WebPages utilizado pelo Razor. Não sei exatamente o motivo, mas o WebPages sobrescreve algumas configurações de Membership para "facilitar" o uso do WebMatrix. Não concordo com a decisão já que o produto principal não é o WebMatrix. De qualquer forma, o problema é o seguinte, já configurei o web.config pra usar Windows Authentication, com e sem impersonate e o primeiro request sempre redirecionava para a url de login que no caso não existe e dá erro 404. Pensei ser um problema do Chrome, mas também acontecia com o Firefox, exceto com o Internet Explorer.

Para solucionar o problema é preciso colocar essa chave no appSettings:

<add key="enableSimpleMembership" value="false"/>

Voltando o Membership ao padrão em vez de sobrescrever pelo Membership do WebPages.

É estranho que o ASP.NET MVC 3 e 4 vem com templates de Intranet e os mesmos não incluem essa chave.

UPDATE: A raiz do problema está na presença da dll WebMatrix.Data.dll. No meu caso ela estava presente pois o projeto foi criado com o template Internet e depois alterado pra Windows Authentication. Removendo essa dll não precisa da chave no web.config

Roslyn September 2012 CTP

9/20/2012 7:55:01 AM By Felipe Pessoto

Mais uma atualização do projeto Roslyn. Agora a maior parte da análise semântica do C# e VB.NET está pronta. Quase todo o C# 3 está implementado, faltando ainda o suporte a dynamic do C# 4 e async/await do C# 5. Também foram feitas várias alterações nas API´s.

Para dar seu feedback, tirar dúvidas e relatar bugs pode usar o Fórum do Roslyn ou o Connect.

O download pode ser feito por este link, ou usando o package do NuGet que contem as API´s que não dependem do Visual Studio.

Read more...

Jogo de Campo Minado (Minesweeper) multiplayer usando C# 5

9/9/2012 5:07:25 PM By Felipe Pessoto

Este projeto é bem antigo, o primeiro que fiz, publiquei os fontes no Codeplex, e fiz uma atualização no código. Ainda tem muitas coisa pra melhorar, mas agora está em .NET 4.5 com C# 5, o que permite fazer todos os IO´s de forma assíncrona sem deixar o código uma bagunça.

No Codeplex fica mais fácil de distribuir e mantém o histórico de alterações, da pra ver como era o código antes de .NET 2.0.

Fujiy Minesweeper

campo minado

Criando NuGet Packages - Parte 1 - Convenções

8/30/2012 8:05:39 AM By Felipe Pessoto

Nos posts anteriores expliquei como criar seu próprio Feed Nuget, mas a grande vantagem é poder publicar seus Packages personalizados, permitindo distribuir para os Developers as bibliotecas usadas na sua empresa.

Antes de começarmos, vou explicar algumas convenções usadas, vou basicamente copiar a documentação original:

Package Id:

Os Packages devem seguir o mesmo padrão de nomenclatura dos namespaces no .NET. Por exemplo, Ninject.Mvc3 em vez de Ninject-Mvc3.

Packages de exemplo: Use o sufixo ".Sample" para o package, por exemplo, se o nome do seu package é Clay, então o exemplo de como usar clay será Clay.Sample. Também, dentro da pasta content, organize seus exemplos dentro de a estrutura /Samples/PackageID. Por exemplo, o package Clay.Sample deverá ter uma pasta /Samples/Clay.

Conteúdo do Package

Pasta App_Start: Quando usar o package WebActivator, coloque todo o código de inicialização da aplicação em uma pasta App_Start dentro da pasta Content. Veja este post para mais detalhes.

Assemblies: Em geral, faz sentigo ter um package por assembly. Em alguns casos, se sua biblioteca tem assemblies que não fazem sentigo em qualquer outro contexto exceto dentro da sua biblioteca, então tudo bem colocar estes assemblies dentro do mesmo package. Por exemplo, se você tem um Foo.dll que depende do Bar.dll e você acha que alguem pode depender do Bar.dll, então faça dois packages. Mas se você tem Foo.dll e Foo.resources.dll, então não faz sentido ter duas packages separadas.

Versionamento do Package

Para entender o versionamento no NuGet, a seguinte série de 3 posts é muito importante (e rápida!) Leia: NuGet Versioning Part 1: Taking on DLL HellPart 2: The core algorithmPart 3: Unification via Binding Redirects.

Escolhendo uma Versão: Em geral, faz sentido version o package de acordo com a versão da biblioteca, mas não esqueça as regras de versionamento que o NuGet usa caso sua biblioteca tem um esquema de versionamento não padronizado. Em geral é recomendado que a versão do package corresponda à biblioteca, mas não é obrigatório.