DÊVIDAS PARA INICIAR NO VB.NET
Amigos, boa tarde.
Estou necessitando de auxÃlio neste nova etapa de aprendizado.
Desenvolvi alguns sistemas (simples) para pequenas e médias empresas considerando a liguagem Visual Basic 6.0 e banco de dados Access.
Agora estou querendo (e vou) migrar para a plataforma .NET (antes tarde do que nunca).
Baixei o VISUAL BASIC 2010 (EXPRESS) e o SQL SERVER 2008 (EXPRESS), porém para iniciar gostaria de tirar algumas dúvidas.
1- Inicialmente começarei o desenvolvimento (Desktop), porém como gerar o arquivo .EXE?
2- Considerando que distribuirei futuramente o sistema, como fazer o pacote de distribuição?
3- Como distribuir a base de dados (SQL) criada juntamente com o meu sistema, considerando que o usuário não tem o SQL SERVER instalado em sua máquina?
Para iniciar esta [Ô]migração[Ô], adquiri um livro (Visual Basic 2010 - Passo a Passo) e um (SQL Server 2008 - Passo a Passo), porém como ainda não tenho segurança em alguns pontos (citados acima), gostaria da ajuda de vcs.
Podem observar que como adquiri os livros, baixei os aplicativos de acordo para não me perder...
Qual a diferença no caso de utilizar neste momento o VB 2010 para o VB2013, creio que a base é a mesma, porém com algumas funcionalidades a mais no VB2013 e o mesmo digo que seja entre o SQL SERVER 2008 (EXPRESS) para o SQL SERVER 2014? O que sugerem?
Poderiam me ajudar...
Grato,
Marcelo Zapia
Estou necessitando de auxÃlio neste nova etapa de aprendizado.
Desenvolvi alguns sistemas (simples) para pequenas e médias empresas considerando a liguagem Visual Basic 6.0 e banco de dados Access.
Agora estou querendo (e vou) migrar para a plataforma .NET (antes tarde do que nunca).
Baixei o VISUAL BASIC 2010 (EXPRESS) e o SQL SERVER 2008 (EXPRESS), porém para iniciar gostaria de tirar algumas dúvidas.
1- Inicialmente começarei o desenvolvimento (Desktop), porém como gerar o arquivo .EXE?
2- Considerando que distribuirei futuramente o sistema, como fazer o pacote de distribuição?
3- Como distribuir a base de dados (SQL) criada juntamente com o meu sistema, considerando que o usuário não tem o SQL SERVER instalado em sua máquina?
Para iniciar esta [Ô]migração[Ô], adquiri um livro (Visual Basic 2010 - Passo a Passo) e um (SQL Server 2008 - Passo a Passo), porém como ainda não tenho segurança em alguns pontos (citados acima), gostaria da ajuda de vcs.
Podem observar que como adquiri os livros, baixei os aplicativos de acordo para não me perder...
Qual a diferença no caso de utilizar neste momento o VB 2010 para o VB2013, creio que a base é a mesma, porém com algumas funcionalidades a mais no VB2013 e o mesmo digo que seja entre o SQL SERVER 2008 (EXPRESS) para o SQL SERVER 2014? O que sugerem?
Poderiam me ajudar...
Grato,
Marcelo Zapia
Citação:1- Inicialmente começarei o desenvolvimento (Desktop), porém como gerar o arquivo .EXE?
2- Considerando que distribuirei futuramente o sistema, como fazer o pacote de distribuição?
3- Como distribuir a base de dados (SQL) criada juntamente com o meu sistema, considerando que o usuário não tem o SQL SERVER instalado em sua máquina?
1. O .exe fica na pasta do teu projeto que você salva, dentro da pasta Bin/Debug como o nome mesmo sugere pra voce gerar um .exe é só clicar em Build/Rebuild e pronto! seu .exe já está atualizadinho na pasta bin/debug.
2. O Pacote de distribuição caso você não utilize muita coisa é simplesmente o .Net Framework não tem ocx e essas coisas todas (isso pra uma aplicação básica)
3. não posso te ajudar pois só utilizo MySql em meus projetos.
Dica: comece pelo Visual Studio 2013 já que já vai aprender, que aprenda com um dos mais [Ô]Avançados[Ô], recomendo utilizar versão Ultimate do VS 2013
Abraços
sobre o BD seja mysql ou sqlserver vc vai precisar de um servidor pra gerenciar o BD, seja local no cliente ou na web sera preciso ter o SGBD.....
através da connection string vc acessa esse arquivo em qq local, mas o local onde ele sera mantido precisa ter instalado o gerenciador....
além da pasta de debug ali, depende como vc compila tem uma forma diferente q seria a final, ai ficaria na pasta RELEASE tmb dentro da pasta bin, mas é um pequeno detalhe na hora de compilar....recomenda-se usar o release realmente qnd a aplicação sera distribuÃda, e debug enquanto em projeto, tanto q no modo release não permite breck points pra ir acompanhando o código....
pacote de distribuição, tem tutoriais q mostram como vc gerar um setup do seu programa, é uma tarefa um pouco grande pra descrever do inicio ao fim, não me recordo se a versão express do VS permite, mas inicialmente vc precisa incluir mais um projeto na sua solução q seria de setup....
as versões posteriores ao VS2010 não tem nativamente a possibilidade de criar o projeto setup, forcando a usar outras saÃdas....ai já recomendaria o Inno Setup, tmb com bom material na net pra ajudar, pode parecer complexo, mas faz todo o trabalho depois....
através da connection string vc acessa esse arquivo em qq local, mas o local onde ele sera mantido precisa ter instalado o gerenciador....
além da pasta de debug ali, depende como vc compila tem uma forma diferente q seria a final, ai ficaria na pasta RELEASE tmb dentro da pasta bin, mas é um pequeno detalhe na hora de compilar....recomenda-se usar o release realmente qnd a aplicação sera distribuÃda, e debug enquanto em projeto, tanto q no modo release não permite breck points pra ir acompanhando o código....
pacote de distribuição, tem tutoriais q mostram como vc gerar um setup do seu programa, é uma tarefa um pouco grande pra descrever do inicio ao fim, não me recordo se a versão express do VS permite, mas inicialmente vc precisa incluir mais um projeto na sua solução q seria de setup....
as versões posteriores ao VS2010 não tem nativamente a possibilidade de criar o projeto setup, forcando a usar outras saÃdas....ai já recomendaria o Inno Setup, tmb com bom material na net pra ajudar, pode parecer complexo, mas faz todo o trabalho depois....
Fala PROVIDER, tudo certo?
Recentemente tive a mesma iniciativa de migrar meus projetos para .NET, pesquisei muito e ainda pesquiso rs..
é interessante suas dúvidas quanto a distribuição, executável, etc..porém o que te aconselho é focar todas suas dúvidas neste novo conceito de desenvolvimento que é a Orientação a objetos.. Não valeria a pena migrar para .NET e continuar desenvolvendo da mesma forma que no bom e velho VB6!
Aqui no forum tem diversos posts, artigos, exemplos sobre o assunto, da uma pesquisada!
Boa sorte e bons estudos!
[]'s
Recentemente tive a mesma iniciativa de migrar meus projetos para .NET, pesquisei muito e ainda pesquiso rs..
é interessante suas dúvidas quanto a distribuição, executável, etc..porém o que te aconselho é focar todas suas dúvidas neste novo conceito de desenvolvimento que é a Orientação a objetos.. Não valeria a pena migrar para .NET e continuar desenvolvendo da mesma forma que no bom e velho VB6!
Aqui no forum tem diversos posts, artigos, exemplos sobre o assunto, da uma pesquisada!
Boa sorte e bons estudos!
[]'s
Ok, o texto provavelmente vai ficar meio longo, mas vamos às dicas:
1 - VB.NET não é simplesmente uma nova versão do VB6. Se você for começar a usar a plataforma .NET(no caso VB.NET) da mesma maneira que usava no VB6, então nem vale à pena migrar, fique no VB6 mesmo. Mesmo porque não existe isso de [Ô]migrar[Ô], você pode até importar o código do VB6 no VB.NET, mas é simplesmente trocar seis por meia dúzia. Se for migrar mesmo, o ideal é reescrever todo o código, usando boas práticas, orientação à objeto, tratamento adequado de exceções, camadas de código e todas essas coisas que, para quem não usa, parece bobagem, mas garanto, não é bobagem. Então antes de começar a sair escrevendo código, estude como essas coisas funcionam, como deve ser feito e então comece a planejar, modelar e desenvolver sua aplicação. Só assim pra valer à pena mesmo.
2 - O banco de dados não é um caso à parte. Ele é parte crucial de qualquer aplicação comercial e deve ter a devida atenção. A modelagem dele é tão ou mais importante que o código em si. Um banco de dados mal modelado é a receita para o desastre da sua aplicação. Então se deve ter atenção com isso também. Afinal, sua aplicação o utiliza o tempo todo e aplicação e banco de dados devem [Ô]conversar[Ô] de forma produtiva. Gambiarras são aceitáveis e fazem as coisas funcionarem, mas simplesmente funcionar não é sinal de que está tudo bem.
3 - Desenvolver a aplicação desktop é praticamente igual(visualmente) ao VB6, arraste e solte componentes e pronto. O caso é que se você não os souber usar de forma correta, vai ter um desempenho bem pior que no VB6. é isso mesmo, uma aplicação .NET mal escrita, vai ser mais lenta que uma equivalente em VB6. E é aà que entram o uso das boas práticas que mencionei no primeiro tópico. Desenvolva pensando em desacoplamento, a independência da interface(telas) do backwork(interação com banco de dados). Se esse desacoplamento for feito corretamente, no momento em que você decidir fazer sua aplicação Web, você não terá retrabalho, que, acredite, é sempre muito e proporcional ao nÃvel de acoplamento.
Quanto às suas dúvidas:
1 - O processo de compilação é o mesmo, porém com alguns detalhes. Primeiro, existem dois tipos basicamente de compilação: Debug e Release. No modo Debug, o executável é colocado na pasta bin\Debug e contém todas as informações para debug, incluindo dumps de memória e breakpoints, ou seja, é com certeza menos eficiente pois é feita para justamente o que o nome dela sugere: debug, ou seja, depuração. A versão de release, não contém essas informações de dumps de memória e breakpoints, por isso ela é muito mais otimizada e eficiente que a versão Debug e é a que você deve distribuir com sua aplicação, assim que terminar de depurar todos os possÃveis erros.
2 - O pacote de instalação consiste em nada mais que sua aplicação e o .NET Framework correspondente. Basta instalar o framework na máquina cliente e sua aplicação vai rodar numa boa, desde que não contenha componentes de terceiros, como por exemplo o Crystal Reports
3 - Em se falando em SQL Server na plataforma .NET, temos várias opções. A ideal é que se instale um servidor SQL em uma das máquinas do cliente para uso com sua aplicação. Ele possui uma versão Express que é gratuita inclusive para uso comercial e altamente aconselhável que a use, pois o ganho em desempenho e praticidade é incomparável com um simples arquivo do access. A distribuição do mesmo tem várias formas. O ideal é que a aplicação possua um script de criação de tabelas, views, triggers e stored procedures necessárias para seu projeto. Assim, você distribui um simples script que pode ser executado pela sua aplicação mesmo e ter seu banco de dados sempre atualizado estruturalmente, sem afetar os dados do cliente.
As suas dúvidas de versionamento qual versão de visual studio, qual versão de SQL Server, são bem tÃpicas de programadores que vêm do VB6. Em se tratando da plataforma .NET, o que realmente importa é a versão do framework. Assim como o VB6, o Visual Studio é um intermediário entre a linguagem humana e a linguagem em que o executável será compilado. Com VB6, você escreve código em visual basic, que ao ser compilado se transforma em dezenas de chamadas para as runtimes do VB6 e API[ô]s do windows. Na plataforma .NET o processo é similar, porém tudo que é necessário é o framework que é o que a versão compilada de sua aplicação realmente usa. Portanto, você pode usar qualquer versão de Visual Studio, pois ele possui retrocompatibilidade(eita palavra difÃcil de digitar), ou seja, você pode usar o visual studio 2015(o mais recente), mas construir uma aplicação usando o framework 2.0(o que seria uma tolice, mas é possÃvel). Não existe VB.NET 2013, 2015, 2010, existe simplesmente VB.NET, versões de framework e de visual studio, que são intercambiáveis. Já com SQL Server, as coisas mudam um pouco, mas não muito. Este sim, possui o versionamento tradicional, onde o mais recente é [Ô]um avanço[Ô] de seu predecessor. Cabe a você verificar o que precisa e o que cada versão de SQL Server oferece. As versões mais atuais, costumam trazer tudo que suas anteriores e ainda compatibilidade, por isso tente usar uma versão mais atual que é o mais indicado.
Em suma:
- Se não for reescrever sua aplicação usando boas práticas e remodelar seu banco de dados de forma correta, nem faça migração pois você vai só estar comprando dores de cabeça futuras.
- Entenda bem como funciona a plataforma .NET e veja que não é uma simples nova versão de VB6, mas sim toda uma gama de recursos.
- Estamos sempre aqui para ajudar, informar e evoluir juntos, por isso, não se acanhe em perguntar, vamos estar sempre dispostos a ajudar, desde que você esteja disposto a aprender e colocar em prática aquilo que aprender.
Boa sorte!
1 - VB.NET não é simplesmente uma nova versão do VB6. Se você for começar a usar a plataforma .NET(no caso VB.NET) da mesma maneira que usava no VB6, então nem vale à pena migrar, fique no VB6 mesmo. Mesmo porque não existe isso de [Ô]migrar[Ô], você pode até importar o código do VB6 no VB.NET, mas é simplesmente trocar seis por meia dúzia. Se for migrar mesmo, o ideal é reescrever todo o código, usando boas práticas, orientação à objeto, tratamento adequado de exceções, camadas de código e todas essas coisas que, para quem não usa, parece bobagem, mas garanto, não é bobagem. Então antes de começar a sair escrevendo código, estude como essas coisas funcionam, como deve ser feito e então comece a planejar, modelar e desenvolver sua aplicação. Só assim pra valer à pena mesmo.
2 - O banco de dados não é um caso à parte. Ele é parte crucial de qualquer aplicação comercial e deve ter a devida atenção. A modelagem dele é tão ou mais importante que o código em si. Um banco de dados mal modelado é a receita para o desastre da sua aplicação. Então se deve ter atenção com isso também. Afinal, sua aplicação o utiliza o tempo todo e aplicação e banco de dados devem [Ô]conversar[Ô] de forma produtiva. Gambiarras são aceitáveis e fazem as coisas funcionarem, mas simplesmente funcionar não é sinal de que está tudo bem.
3 - Desenvolver a aplicação desktop é praticamente igual(visualmente) ao VB6, arraste e solte componentes e pronto. O caso é que se você não os souber usar de forma correta, vai ter um desempenho bem pior que no VB6. é isso mesmo, uma aplicação .NET mal escrita, vai ser mais lenta que uma equivalente em VB6. E é aà que entram o uso das boas práticas que mencionei no primeiro tópico. Desenvolva pensando em desacoplamento, a independência da interface(telas) do backwork(interação com banco de dados). Se esse desacoplamento for feito corretamente, no momento em que você decidir fazer sua aplicação Web, você não terá retrabalho, que, acredite, é sempre muito e proporcional ao nÃvel de acoplamento.
Quanto às suas dúvidas:
1 - O processo de compilação é o mesmo, porém com alguns detalhes. Primeiro, existem dois tipos basicamente de compilação: Debug e Release. No modo Debug, o executável é colocado na pasta bin\Debug e contém todas as informações para debug, incluindo dumps de memória e breakpoints, ou seja, é com certeza menos eficiente pois é feita para justamente o que o nome dela sugere: debug, ou seja, depuração. A versão de release, não contém essas informações de dumps de memória e breakpoints, por isso ela é muito mais otimizada e eficiente que a versão Debug e é a que você deve distribuir com sua aplicação, assim que terminar de depurar todos os possÃveis erros.
2 - O pacote de instalação consiste em nada mais que sua aplicação e o .NET Framework correspondente. Basta instalar o framework na máquina cliente e sua aplicação vai rodar numa boa, desde que não contenha componentes de terceiros, como por exemplo o Crystal Reports
3 - Em se falando em SQL Server na plataforma .NET, temos várias opções. A ideal é que se instale um servidor SQL em uma das máquinas do cliente para uso com sua aplicação. Ele possui uma versão Express que é gratuita inclusive para uso comercial e altamente aconselhável que a use, pois o ganho em desempenho e praticidade é incomparável com um simples arquivo do access. A distribuição do mesmo tem várias formas. O ideal é que a aplicação possua um script de criação de tabelas, views, triggers e stored procedures necessárias para seu projeto. Assim, você distribui um simples script que pode ser executado pela sua aplicação mesmo e ter seu banco de dados sempre atualizado estruturalmente, sem afetar os dados do cliente.
As suas dúvidas de versionamento qual versão de visual studio, qual versão de SQL Server, são bem tÃpicas de programadores que vêm do VB6. Em se tratando da plataforma .NET, o que realmente importa é a versão do framework. Assim como o VB6, o Visual Studio é um intermediário entre a linguagem humana e a linguagem em que o executável será compilado. Com VB6, você escreve código em visual basic, que ao ser compilado se transforma em dezenas de chamadas para as runtimes do VB6 e API[ô]s do windows. Na plataforma .NET o processo é similar, porém tudo que é necessário é o framework que é o que a versão compilada de sua aplicação realmente usa. Portanto, você pode usar qualquer versão de Visual Studio, pois ele possui retrocompatibilidade(eita palavra difÃcil de digitar), ou seja, você pode usar o visual studio 2015(o mais recente), mas construir uma aplicação usando o framework 2.0(o que seria uma tolice, mas é possÃvel). Não existe VB.NET 2013, 2015, 2010, existe simplesmente VB.NET, versões de framework e de visual studio, que são intercambiáveis. Já com SQL Server, as coisas mudam um pouco, mas não muito. Este sim, possui o versionamento tradicional, onde o mais recente é [Ô]um avanço[Ô] de seu predecessor. Cabe a você verificar o que precisa e o que cada versão de SQL Server oferece. As versões mais atuais, costumam trazer tudo que suas anteriores e ainda compatibilidade, por isso tente usar uma versão mais atual que é o mais indicado.
Em suma:
- Se não for reescrever sua aplicação usando boas práticas e remodelar seu banco de dados de forma correta, nem faça migração pois você vai só estar comprando dores de cabeça futuras.
- Entenda bem como funciona a plataforma .NET e veja que não é uma simples nova versão de VB6, mas sim toda uma gama de recursos.
- Estamos sempre aqui para ajudar, informar e evoluir juntos, por isso, não se acanhe em perguntar, vamos estar sempre dispostos a ajudar, desde que você esteja disposto a aprender e colocar em prática aquilo que aprender.
Boa sorte!
Kerplunk continua um superdidata .....
eu queria migrar também ....... pois não pretendo ficar viuvo do VB6.
Aà que está o problema, todo mundo fala desse gururu e não explica o que vem a ser .... já là or artigos do Macoratti mesmo assim não vejo tãooooo grande coisa. ai pergunto: O que são boas práticas de programação para a plataforma Net? ....
Sei que não existe programação perfeita ...... mais eu queria chegar perto lá
eu queria migrar também ....... pois não pretendo ficar viuvo do VB6.
Citação:Se não for reescrever sua aplicação usando boas práticas e remodelar seu banco de dados de forma correta, nem faça migração pois você vai só estar comprando dores de cabeça futuras
Aà que está o problema, todo mundo fala desse gururu e não explica o que vem a ser .... já là or artigos do Macoratti mesmo assim não vejo tãooooo grande coisa. ai pergunto: O que são boas práticas de programação para a plataforma Net? ....
Sei que não existe programação perfeita ...... mais eu queria chegar perto lá
Bem, exemplificando de maneira bem grosseira:
No VB6 você tem um form com um campo e um botão. Quando clicar no botão, consultar a tabela [Ô]Clientes[Ô] por nome, sendo que como parâmetro usar o que estiver escrito no campo do form, geralmente se faria algo como:
Simples, sem muita coisa pra dar dor de cabeça. No .NET uma das muitas técnicas de boas práticas, é a OOP, a famosa orientação a objeto. Com ela se faria:
Isso é só uma idéia, um esboço, mas a simples função [Ô]Search[Ô] do objeto Cliente, recebe o nome do campo e o valor a ser procurado, faz a procura e coloca o resultado da procura no objeto [Ô]SearchResult[Ô] que contém uma Lista<Clientes>, ao qual é a fonte de dados para o grid [Ô]grdClientes[Ô], que simplesmente recebe esses dados e preenche, tudo de forma automática. Esse objeto [Ô]Cliente[Ô] estaria em um projeto separado, totalmente independente da interface gráfica. Nele usa-se tratamento de exceções adequado, logs, regras de negócio e tudo mais que é referente à cliente, ficaria nesse projeto, que é apenas referenciado no projeto da interface gráfica. O projeto da interface gráfica por sua vez, não teria uma única referência à banco de dados, sendo impossÃvel acessar o banco de dados diretamente dele. Qualquer coisa que se queira do banco de dados, você vai criar objetos e métodos referentes ao que se quer no projeto da em que [Ô]Cliente[Ô] está, e esse sim, tem referências à banco de dados.
Isso de maneira muito grosseira mesmo, as boas práticas, não são somente a OOP, mas sim, um conjunto enorme de regras bem flexÃveis que se aplicam caso a caso. Modos de se programar, como no exemplo acima, onde tenho um método que retorna dados em uma propriedade da classe, poderiam ser totalmente diferentes:
Esta também é uma maneira. Cabe ao desenvolvedor/engenheiro/analista ou uma combinação de todos decidirem isso, ou seja, qual o padrão de programação a ser usado, porque ser usado e tudo o mais.
Não sei se me fiz entender...
No VB6 você tem um form com um campo e um botão. Quando clicar no botão, consultar a tabela [Ô]Clientes[Ô] por nome, sendo que como parâmetro usar o que estiver escrito no campo do form, geralmente se faria algo como:
public sub btnConsultar_Click()
dim cn as new Connection
dim rs as new Recordset
set cn = new Connection
cn.Open [Ô]bla bla bla connection string[Ô]
Set rs = new Recordset
rs.Open [Ô]Select * from clientes where Nome like [ô]%[Ô] & txtNome & [Ô][ô][Ô], cn
do while not rs.eof
(preenchendo dados de um grid)
rs.movenext
loop
end sub
Simples, sem muita coisa pra dar dor de cabeça. No .NET uma das muitas técnicas de boas práticas, é a OOP, a famosa orientação a objeto. Com ela se faria:
Dim cliente As New Cliente
Cliente.Search([Ô]Nome[Ô], txtNome.Text)
grdClientes.DataSource = Cliente.SearchResult
Isso é só uma idéia, um esboço, mas a simples função [Ô]Search[Ô] do objeto Cliente, recebe o nome do campo e o valor a ser procurado, faz a procura e coloca o resultado da procura no objeto [Ô]SearchResult[Ô] que contém uma Lista<Clientes>, ao qual é a fonte de dados para o grid [Ô]grdClientes[Ô], que simplesmente recebe esses dados e preenche, tudo de forma automática. Esse objeto [Ô]Cliente[Ô] estaria em um projeto separado, totalmente independente da interface gráfica. Nele usa-se tratamento de exceções adequado, logs, regras de negócio e tudo mais que é referente à cliente, ficaria nesse projeto, que é apenas referenciado no projeto da interface gráfica. O projeto da interface gráfica por sua vez, não teria uma única referência à banco de dados, sendo impossÃvel acessar o banco de dados diretamente dele. Qualquer coisa que se queira do banco de dados, você vai criar objetos e métodos referentes ao que se quer no projeto da em que [Ô]Cliente[Ô] está, e esse sim, tem referências à banco de dados.
Isso de maneira muito grosseira mesmo, as boas práticas, não são somente a OOP, mas sim, um conjunto enorme de regras bem flexÃveis que se aplicam caso a caso. Modos de se programar, como no exemplo acima, onde tenho um método que retorna dados em uma propriedade da classe, poderiam ser totalmente diferentes:
Dim cliente As New Cliente
Dim resultado As New List(Of Cliente)
cliente.Tipo = 4
resultado = cliente.Procurar()
grdResultado = resultado
Esta também é uma maneira. Cabe ao desenvolvedor/engenheiro/analista ou uma combinação de todos decidirem isso, ou seja, qual o padrão de programação a ser usado, porque ser usado e tudo o mais.
Não sei se me fiz entender...
Citação:Em se tratando da plataforma .NET, o que realmente importa é a versão do framework. Assim como o VB6, o Visual Studio é um intermediário entre a linguagem humana e a linguagem em que o executável será compilado. Com VB6, você escreve código em visual basic, que ao ser compilado se transforma em dezenas de chamadas para as runtimes do VB6 e API[ô]s do windows. Na plataforma .NET o processo é similar, porém tudo que é necessário é o framework que é o que a versão compilada de sua aplicação realmente usa. Portanto, você pode usar qualquer versão de Visual Studio, pois ele possui retrocompatibilidade(eita palavra difÃcil de digitar), ou seja, você pode usar o visual studio 2015(o mais recente), mas construir uma aplicação usando o framework 2.0(o que seria uma tolice, mas é possÃvel). Não existe VB.NET 2013, 2015, 2010, existe simplesmente VB.NET, versões de framework e de visual studio, que são intercambiáveis.
Bom, não quero ser dramático, mas eu là por aqui no site que VB.Net estava compativel em recursos com o C#, isso desde a versão 2013 se não me engano.
Se essa informação está correta, onde fica o framework sendo que tanto o VB como o C# utilizam a mesma framework?
Acho essas informações redundantes em contradição ..... se é que interpretei certo.
No tange a sua explicação é legivel e compreensÃvel .... mas eu acho que vai muito alem ... não dá pra falar em poucas palavras .... como vc mesmo disse a equipe deve decidir qual caminho seguir ... e abandonar práticas do VB6 vai levar muiiiiiiito tempo ...... pra assimilar a boas práticas.
Mais outro coisa .... até onde sei também pode-se usar Visual Studio até a versão 2005 pra fazer classes para ser utilizadas no VB6 ... tipo arquivo tlb.
somando-se a versão diz alguma coisa ..... penso eu.
somando-se a versão diz alguma coisa ..... penso eu.
KERPLUNK
Eu sempre executei o programa para debug, ia no bin\debug e pegava o executável para dar ao cliente, pelo jeito não estou fazendo corretamente.
como compilo no modo release? Compilo o solution?
Eu sempre executei o programa para debug, ia no bin\debug e pegava o executável para dar ao cliente, pelo jeito não estou fazendo corretamente.
como compilo no modo release? Compilo o solution?
JCM0867
- Vá em Build > Configuration Manager >
- em Active solution configurarion altere para Release e clica no Close.
- Depois, Build > Build Solution
Por fim só copiar o arquivo em bin\Release
* Me corrijam se estiver errado, mas faço dessa forma;
- Vá em Build > Configuration Manager >
- em Active solution configurarion altere para Release e clica no Close.
- Depois, Build > Build Solution
Por fim só copiar o arquivo em bin\Release
* Me corrijam se estiver errado, mas faço dessa forma;
Faça seu login para responder