Fujiy

Blog sobre .NET, C#, ASP.NET entre outras tecnologias de desenvolvimento de software

Roslyn June 2012 CTP

06/06/2012 07:45:50 Por Fujiy

Anunciada uma nova versão do Roslyn, projeto que permite usar o compilador de C# e VB.NET como um serviço, agora suportando o Visual Studio 2012 RC e com algumas novidades em relação ao suporte a linguagem:

  • Tipos anônimos
  • Queries
  • Eventos
  • Índices
  • Parametros Nomeados e Opcionais
  • Algumas outras expressões (using, lock/SyncLock, etc)

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.

Configurando Beyond Compare no TFS

30/05/2012 07:48:33 Por Fujiy

Uma dica pra quem prefere o Beyond Compare (na minha opinião, a melhor ferramente de comparação), é possível usar ele no TFS. Pra isso é só seguir os seguintes passos

  1. Abrir o menu Tools -> Option
  2. No menu lateral, escolha Source Control. Se a Visual Studio Team Foundation Server não estiver selecionado, selecione.
  3. De volta ao menu lateral, selecione o item Visual Studio Team Foundation Server dentro de Source Control.
  4. Clique no botão Configure User Toolse adicione a seguinte entrada:
    • Extension: .*
    • Operation: Compare
    • Command: O caminho pro BComp.exe, no meu caso: C:\Program Files (x86)\Beyond Compare 3\BComp.exe
    • Arguments: %1 %2 /title1=%6 /title2=%7
  5. Se quiser usar o Beyond Compare para Merge também, adicione mais uma entrada com os seguintes parâmetros:
    • Extension: .*
    • Operation: Merge
    • Command: O caminho pro BComp.exe, no meu caso: C:\Program Files (x86)\Beyond Compare 3\BComp.exe
    • Arguments: %1 %2 %3 %4 /title1=%6 /title2=%7 /title3=%8 /title4=%9

Running & Scripting Migrations From Code

10/05/2012 00:16:34 Por Fujiy

Rowan Miller explained how to script Migrations from code, but his code was write using a pre-RTM version of Code First Migrations and doesn´t work when using EntityFramework 4.3.1.

I did some reflector work and get a solution that should work.

The most obvious difference is that some classes was renamed. Another point, at least in my case I needed to configure some additional things, like MigrationsAssembly
and MigrationsNamespace, these properties are used to find Code-Based migrations, that is what I want instead of use Automatic Migrations.

The code that does the magic:

System.Data.Entity.Migrations.DbMigrationsConfiguration configuration =newSystem.Data.Entity.Migrations.DbMigrationsConfiguration();
configuration
.ContextType=typeof(FujiyBlogDatabase);//TODO Change to your DbContext
configuration
.MigrationsAssembly= configuration.ContextType.Assembly;
configuration
.MigrationsNamespace="FujiyBlog.Core.Migrations";//TODO Namespace that contains your migrations classes

var migrator =new System.Data.Entity.Migrations.DbMigrator(configuration);

if(true)//TODO Do you want the script or Update de database?
{
   
var scriptor =newSystem.Data.Entity.Migrations.Infrastructure.MigratorScriptingDecorator(migrator);
   
string script = scriptor.ScriptUpdate(sourceMigration:null, targetMigration:null);
}
else
{
    migrator
.Update();
}

FujiyBlog vNext - Automatic Migrations

10/05/2012 00:05:24 Por Fujiy

Com o suporte ao unicode aproveitei pra testar a criação das migrations e scripts SQL. Há algum tempo tentei automatizar o processo, seguindo o post do Rowan Miller, PM de ADO.NET Entity Framework, Running & Scripting Migrations From Code, mas não funciona pelo menos na versão 4.3.1. Cheguei a comentar no post mas não tive resposta.

O jeito foi tentar entender o código que faz o Migration, usando o decompiler do Resharper. Consegui chegar num resultado que permite a migração totalmente automática, quando se tem as permissões necessárias no banco de dados, ou a geração do Script dinamicamente. Pretendo criar um post explicando o processo, que é bem simples, e (tentar) fazer uma versão em inglês pois vi que tem várias pessoas com o mesmo problema que tive.

FujiyBlog vNext - Unicode Support

09/05/2012 23:55:01 Por Fujiy

A próxima versão, provavelmente v0.4 terá suporte para unicode em todas as strings, como títulos, corpo, nome de categorias, tags, etc. Pra quem usa SQL CE não muda nada, já que ele só suporta NVARCHAR, então obrigatoriamente desde a primeira versão suporta Unicode.

Inicialmente limitei as strings em VARCHAR por eficiência, mas como o sistema é aberto, a prioridade é ser o mais abrangente possível. Por exemplo, já temos usuários em outros idiomas, um deles é chinês, http://blog.ip188.net, por sorte ele usou SQL CE então não teve problemas, mas se tivesse usando SQL Server não teria conseguido salvar textos com caracteres além dos ASCII.