Estive pesquisando alguma maneira de ler o xml criada no delphi para minha aplicação desenvolvida em c#, porém não consegui encontrar nada que me ajudasse,
no entanto acabei criando uma rotina própria que fizesse isso pra min, irei deixar o código abaixo para quem mais estiver interessado..
Qualquer coisa..dúvidas...comentem!!

 private DataRow addDataRowValue(XmlAttribute xmlAttribute, DataRow dataRow, DataTable dataTable)
        {
            if (xmlAttribute != null)
            {
                if (!dataTable.Columns.Contains(xmlAttribute.Name))
                    dataTable.Columns.Add(xmlAttribute.Name);
                dataRow[xmlAttribute.Name] = xmlAttribute.Value;
            }
            return dataRow;
        }
        public void converteDataPacketXml(FileInfo fileInfo, string nomeXml)
        {
            DataColumn dataColumn = new DataColumn();
            DataTable dataTable = new DataTable(nomeXml);
            XmlDocument xml = new XmlDocument();
            xml.Load(fileInfo.FullName);
            foreach (XmlNode no in xml.GetElementsByTagName(@"ROW"))
            {
                DataRow dataRow = dataTable.NewRow();
                foreach (XmlAttribute xmlAtribute in no.Attributes)
                {
                    dataRow = addDataRowValue(no.Attributes[xmlAtribute.Name], dataRow, dataTable);
                }
                dataTable.Rows.Add(dataRow);
            }
            fileInfo.Delete();
            dataTable.WriteXml(fileInfo.FullName);
        }

Muitas discussões dos desenvolvedores sobre se devem usar ou aprender a ASP.NET MVC tem sido recorrente em blogs, Twitter e fóruns nas últimas semanas.  As opiniões variam de não recomendar até ao ponto de que todos os desenvolvedores deveriam aprender. InfoQ tentou resumir um pouco da recente atividade em relação a este tópico.

Rob Conerey (funcionário da Microsoft no time de ASP.NET MVC e criador do SubSonic) explica porque desenvolvedores deveriam aprender ASP.NET MVC, depois de observar questões levantadas na comunidade.

Em sua introdução ele começa descrevendo WebForms como "A Grande Mentira":

WebForms é uma mentira. Sua abstração embrulhada em decepção coberta com molho de mentira servido em um prato cheio de diversão e um truque bem pensado. Nada que você faz com WebForms tem é ver com Web - você deixa ele fazer o trabalho para você.

Isto, amigos, é algo importante (pelo menos para mim): Você está trabalhando em uma mentira. A web não é 'stateful' e trabalha com esta coisa chamada HTML enviada através de fios usando outra coisa chamada HTTP - você precisa sabê-los, amá-los e senti-los nas suas veias.

Rob lista 7 razões para usar ASP.NET MVC ou em suas próprias palavras - 7 Razões Para Parar de Me Chamar De Idiota:

1. Testabilidade
2. Controle sobre HTML
3. Extensibilidade
4. Faz você pensar
5. ...Diferentemente: Javascript não enche o saco
6. Aprendendo novos conceitos
7. É engraçado

E conclui que:

Ponto proncipal: Eu estou me divertindo novamente ao programar web e acho que é muito motivador, pelo menos para mim e para meus gatos. Ainda uma comparação, com certeza, mas acredito que um pouco mais direto. Você não tem nenhum motivo para não aprender MVC "mas vou permitir que possa ter uma razão ou duas para você continuar com WebForms."

Joe Brinkman (desenvolvedor em tempo integral noDotNetNuke) rapidamente seguiu com uma resposta, criticando Rob por não escolher "UMA BOA razão para aprender MVC", e lista sua própria:

1. Vai te expor a uma arquitetura diferente
2. Você será forçado a se tornar intimamente faimilar com HTML e HTTP
3. MVC promove testes unitários
4. MVC o fará ver o quanto você ganha por lidar com WebForms

Joe conclui dizendo:

Então em resumo, você deve realmente conferir MVC.  Mas não pelas razões que Rob enumerou.  Você deve explorar MVC porque ao final você pode ter aprendido algo que o fará um programador web melhor, não importa que plataforma você escolha.

Rob e Joe basicamente concordam no mesmo, que desenvolvedores ASP.NET devem aprender ASP.NET MVC, mas discordam no porquê dos argumentos.Karl Seguin no entanto tem uma diferente opinião e pergunta "se ASP.NET é uma solução crua"?:

Ser capaz de escrever sistemas complexos de uma maneira limpa é um bom começo, mas dado onde o desenvolvimento web geralmente se encontra, e outras plataformas em específico, ASP.NET MVC larga muito atrás (Perl sendo a única que eu consigo pensar que é pior).

Há uma pequena questão que uma grande parte do problema é que este é realmente um stack VC - não há pensamento, suporte e ferramentas para o Modelo. Quando você compara as milhares de linhas que você vai acabar escrevendo para seu repositório/dal/linq/nhiberate para outros stacks MVC (que normalmente somente requerem que seus modelos herdem de uma classe), você já está em uma série desvantagem de produtividade. Mas o real impacto é na verdade muito pior - você perde qualquer coesão de propósito através dos controllers e views. Não há maneira de gerar labels HTML de propriedades modelo, ou validação no lado do cliente.
...
Existem algumas boas notícias, e que toda esta "infraestrutura" é reutilizada, que fazem projetos como S#arp Architecture possíveis. No entanto, eu ainda estou cético que estes projetos possam realmente ter sucesso contra frameworks melhor integrados.

 Jeremy D. Miller (um dos criadores do FubuMVC) lista alguns prós e contras:

CONTRAS:
"o framework MVC não é eficiente a não ser que você planeje arregaçar as mangas e produzir uma infraestrutura específica para seu projeto para preencher no "M", atingir melhor testabilidade, sincronização de tela mais fácil, e HTML helpers mais produtivos"

...
PRÓS:
É muito fácil e direto para pegar o framework MVC pelos chifres e customizar para seu benefício.

Jeremy conclui dizendo:

Eu fico com a afirmação que o ASP.Net MVC framework, no fim das contas, é uma melhor maneira de construir aplicações web que a "abstração embrulhada em decepção coberta com molho de mentira servido em um prato cheio de diversão e um truque bem pensado,"  mas neste ponto é provavelmente uma ferramenta restrita para amigos que sejam do tipo "early adopters"

Jeffrey Palermo (atualmente escrevendo o livro “ASP.NET MVC in action”) declara que “Você não deve usar ASP.NET MVC se…”:

• Você não esta muito confortável com polimorfismo
• Você não deseja escrever no topo de um framework
• Você utiliza controles de terceiros para muito da interface de usu?rio
• Você é contra utilizar bibliotecas open-source

Mas continua com:

O framework ASP.NET MVC é um framework facilitador.  Não é um framework que "pega na sua mão".   Não é um framework “ASP.NET 101” .  Você tem controle total sobre tudo.  Padrões de interface de usuário no espaço da Web não são tão padronizados para que nós possamos abandonar controles para usar frameworks que trabalham de uma maneira "padrão".   Acesso a dados alcançou este ponto onde nós sabemos que precisamos Criar, Ler, Atualizar e Apagar, cascateando persistência, lazy loading, etc.   Existe muitos mapeadores objeto-relacional (ORM) que suportam as operações comuns, e muitos desenvolvedores estão satisfeitos desistindo do controle completo sobre o acesso a dados devido a forma parecida que os ORMs líderes trabalham (Hibernate/NHibernate).

Existem é claro muitos outros que expressaram as suas opiniões, mas InfoQ acha que as acima resumem muitos dos argumentos a favor e contra de aprender/usar ASP.NET MVC.

Coteúdo do Site: http://www.infoq.com/br/news/2009/05/should-devs-learn-aspnetmvc
Postado por Jon Arild Tørresdal , traduzido por André Pantalião em 12 Mai 2009 05:06 PM

Segue exemplo prático 

            List<ProdutoBean> testeList = new  List<ProdutoBean>();
           
            ProdutoBean produtoBean = new ProdutoBean();
            produtoBean.proNome = "c";
            testeList.Add(produtoBean);

            produtoBean = new ProdutoBean();
            produtoBean.proNome = "b";
            testeList.Add(produtoBean);

             produtoBean = new ProdutoBean();
             produtoBean.proNome = "a";
             testeList.Add(produtoBean);

            System.Collections.Generic.IEnumerable<ProdutoBean> teste = testeList;
            teste = teste.OrderBy(i => i.proNome);

//Para repassar para a lista novamente use o método toList()
             
            testeList = teste.ToList();

Essa é uma das funcionalidade imbutidas .NET, interessante pela razão de não termos a nescessidade de utilizar duas consultas para efetuar a mesma funcionalidade, como por exemplo:

ao invés de:

if ((variavel != "") && (variavel != null)){
...
}

Você faz:
if (!String.IsNullOrEmpty(s)){
...
}


Indica se o objeto String especificado é uma referência nula (Nothing no Visual Basic) ou uma seqüência vazia (Empty string).


Qualquer dúvida mais detalhes aqui:
http://msdn.microsoft.com/pt-br/library/system.string.isnullorempty.aspx

O nosso dia a dia é sempre cheio de novidades e isso que deixa os nossos projetos cada vez mais divertidos. Hoje eu tive que fazer alguns ajustes em uma aplicação que está rodando no root do servidor web e possui outras aplicações rodando em baixo dessa mesma pasta.

A grande questão envolvida é que as configurações que inserimos no Web.Config da aplicação principal são propagadas para a aplicação que está em baixo da mesma estrutura de diretório conforme o modelo:

APP00 (Root) (Web.config)
+-----App01 (Web.config)
+-----App02 (Web.config)

Então de uma forma natural você acaba injetando dependências nas outras aplicações que está em baixo dessa mesma estrutura de diretório. Para resolver isso você precisa agir no Web.Config da aplicação principal e adicionar o atributo location com o parâmetro inheritInChildApplications="false" para impedir que configurações sejam propagadas para as outras aplicações. Essa necessidade se torna muito visível principalmente quando você adiciona referencias para módulos http em <system.Web>

<location path="." inheritInChildApplications="false">
    <system.web>
   </system.web>  
</location>

- How to disable web.config Inheritance for Child Applications in Subfolders in ASP.NET
- Bloqueando herança do web.config

Fonte:http://www.ramonduraes.net/post/Heranca-de-configuracoes-no-WebConfig.aspx
[],
Ramon Durães
MVP, Especialista em Visual Studio Team System

Demonstração de um primeiro projeto em Visual C# 2008 Express Edition usando Console Application. Parte 2 de 2.

Demonstração de um primeiro projeto em Visual C# 2008 Express Edition usando Console Application. Parte 1 de 2.

Introdução

Este curso destina-se aqueles que desejam iniciar o aprendizado na linguagem C# desenvolvida especialmente para a plataforma .NET. Ao acompanhar este artigo você aprenderá a criar pequenos aplicativos para desktop. Veremos aqui os conceitos básicos da linguagem C# e a IDE Visual Studio, para um melhor aproveitamento do .NET Framework. Para um melhor entendimento dos artigos que se seguem, é importante conhecimento em lógica de programação.

A linguagem

A linguagem de programação C# (lê-se C Sharp) surge como uma evolução da linguagem "C" e destina-se a aplicações utilizando o .NET Framework, utilizando os novos conceitos de Orientação a Objetos (OO).

O .NET Framework

Basicamente definido como um componente integral do Windows responsável por fornecer os serviços necessários, para construção e carregamento de aplicações para Windows e Web.

O . NET Framework utiliza o CLR (Common Language Run Time) sendo uma base para o .NET Framework, disponibilizando:

• Interoperabilidade de linguagem;

• Suporte de versões aprimorado;

• Segurança aprimorada;

• Garbage Colection.

Também utiliza o Framework Class Library (Biblioteca de Classes) e tem como agente um serviço de Run Time que gerencia o código durante a execução do aplicativo.

Definição de variáveis

Veremos aqui os tipos de variáveis mais utilizadas no desenvolvimento de softwares. Variáveis são definidas como locais de armazenamento temporário de diferentes tipos como: números, palavras, datas e outros, que podem receber resultados de cálculos ou entrada de dados pelo usuário.

As variáveis devem receber um nome único (dentro de um escopo), para que seja usado como referência ao decorrer do desenvolvimento e deve ter um nome curto e de fácil memorização, não sendo recomendado utilizar variáveis com o mesmo nome diferenciando-as somente por maiúsculas e minúsculas.

Exemplo:
nomecliente
nomeCliente
    
Isso pode causar confusão para o desenvolvedor, ou seja, usualmente as variáveis são escritas com a primeira letra minúscula e se tiver mais de uma palavra a segunda palavra com a primeira letra maiúscula.

Exemplo:
nomeCliente
sobrenomeCliente
idadeCliente
    
Outra prática muito utilizada hoje pelas empresas para um melhor entendimento das variáveis e também para facilitar a manutenção do seu código é no início de cada variável inserir letras minúsculas indicando o tipo da variável que você declarou no inicio do código.

Exemplo:
strNomeCliente (variável do tipo string)
intIdadeCliente (variável do tipo int)
    
Veja abaixo as variáveis mais utilizadas no desenvolvimento de softwares em C#:

Descrição dos tipos de dados:
int = Números inteiros (32 bits por padrão)
long = Números inteiros (64 bits por padrão)
float = Números de ponto flutuante (32 bits por padrão)
double = Números de ponto flutuante (63 bits por padrão)
decimal = Valores monetários (128 bits por padrão)
string = Para seqüências de caracteres (16 bits por caractere)
char = Para somente um caractere (16 bits)
bool = Valor booleano que pode ser (true) ou (false)

Para atribuição de valores as variáveis citadas acima você deve utilizar o sinal de (=) que se trata de um operador lógico que veremos nas próximas aulas.

Exemplos de uso das variáveis:
int intIdade = 10;
bool booFumante = false;
decimal decPagamento = 1000;
double dblComissão = 1.27;
char chrSexo = M;
string strNome = "Einstein";
    
Ao término da declaração de cada variável deve-se usar (;) para que o Visual Studio entenda que ali se encerra a declaração da variável.

Conclusão

Este é o primeiro de uma série de artigos para iniciantes da linguagem C# deixando aberto a idéias e dúvidas através do e-mail: carlos.andrade@fcamara.com.br.
No próximo artigo iremos aprender sobre operadores lógicos e sua utilização.
Criado por: Carlos Andrade
REF:http://www.oficinadanet.com.br

Veja parte 2 em Curso Básico de C# - Parte 2 - Operadores

Duas classes são nescessarias:

FirebirdSql.Web.Providers.FbMembershipProvider e FirebirdSql.Web.Providers.FbProfileProvider

quem estarão presentes na biblioteca do firebird.

Depois será nescessário ter a estrutura do banco de dados:

Baixe aqui o Script script.sql (50,91 kb)

Configure o Web.Config para receber a nova estrutura:

...
<membership defaultProvider="FireBirdMembershipProvider">

    <providers>

        <clear/>

        <add name="FireBirdMembershipProvider" connectionStringName="AspNetSecurity" applicationName="/" type="FirebirdSql.Web.Providers.FbMembershipProvider" passwordFormat="Clear"/>

    </providers>

</membership>

<profile defaultProvider="FireBirdProfileProvider" enabled="true">

    <properties>

        <add name="Age" type="Int32"/>

        <add name="Country" type="String"/>

    </properties>

    <providers>

        <clear/>

        <add name="FireBirdProfileProvider" connectionStringName="AspNetSecurity" applicationName="/" type="FirebirdSql.Web.Providers.FbProfileProvider"/>

    </providers>

</profile>

<roleManager defaultProvider="FireBirdRoleProvider" enabled="true">

    <providers>

        <clear/>

        <add name="FireBirdRoleProvider" connectionStringName="AspNetSecurity" applicationName="/" type="FirebirdSql.Web.Providers.FbRoleProvider"/>

    </providers>

</roleManager> 

...
Acho que é isso pessoal, qualquer dúvida deixe uma mensagem ai que respondo.