Não reinvente a roda! Utilize componentes prontos no desenvolvimento da sua aplicação

Por André Lima em 15/02/2017

Embarcados

Muitos desenvolvedores não sabem da existência de bibliotecas comerciais e acabam constantemente “reinventando a roda” na hora de desenvolver as suas aplicações. Eu mesmo, lá por volta de 2005, no começo da minha carreira, não conhecia tais bibliotecas e pacotes de componentes. Ou seja, eu desenvolvia as aplicações da pequena empresa onde eu trabalhava utilizando os componentes nativos do Windows Forms.

Foi só depois de participar de uma mesa redonda no TechEd (em 2006, se não me engano) que eu ouvi falar da DevExpress e fui pesquisar exatamente o que ela tinha a oferecer. Começamos a utilizar os componentes de avaliação e a produtividade foi às alturas. Não dá para comparar a quantidade de funcionalidades disponíveis nos controles de bibliotecas comerciais com as funcionalidades dos controles nativos do .NET Framework.

É justamente por causa desse grande impacto que essa simples informação fez no desenvolvimento das nossas aplicações que eu quero compartilhar com você as 4 principais empresas que desenvolvem bibliotecas de componentes para aplicações .NET (entre outras plataformas).

Edit: depois de publicar e divulgar este artigo, várias pessoas me lembraram nos comentários (tanto aqui quanto no Facebook) da SyncFusion! Eu realmente tinha esquecido da SyncFusion, que tem até uma licença gratuita “Community” (como o Visual Studio) para desenvolvedores individuais e empresas que faturem menos que $1 milhão por ano.

Só para deixar claro, não existem somente essas empresas que vendem componentes prontos para o desenvolvimento de aplicações .NET. Essas são, na minha opinião, as 4 empresas mais conhecidas do segmento. Caso você utilize componentes de alguma outra empresa, deixe o seu comentário no final do artigo.

Ah, outro detalhe: esse não é um post patrocinado. Ou seja, não estou ganhando absolutamente nada dessas empresas para fazer essa divulgação. Só estou divulgando porque, como falei anteriormente, essa informação teve um grande impacto nas aplicações que desenvolvemos dali para a frente.

DevExpress

A DevExpress foi a primeira empresa desse ramo que eu tive contato. Na empresa onde eu trabalhava na época eu baixei os componentes de avaliação e fiquei maravilhado com as suas funcionalidades. O destaque vai para o famoso grid, que possui nativamente as funcionalidades de ordenação, remoção e adição de colunas, filtros, mestre/detalhe, drilldown, agrupamentos, entre outras:

E não é só o grid que faz sucesso. O pacote de componentes da DevExpress conta também com controles de layout (possibilitando que o usuário altere o layout das telas e salve para a próxima execução), gráficos, ribbon, skins, entre outros. Dá uma olhada nas plataformas suportadas no momento:

E quanto é que custa tudo isso? Bom, não é barato. No momento da escrita deste artigo (fevereiro de 2017), se você for comprar as plataformas separadamente (por exemplo, só Windows Forms ou só WPF ou só ASP.NET), elas custarão entre $500 e $900, dando o direito de suporte e atualizações por um ano. Depois disso, se você quiser continuar com o suporte e novas atualizações, você tem que renovar a cada ano (por um preço menor).

Existe também a opção de você comprar os componentes de todas as plataformas .NET (Windows Forms, ASP.NET, WPF e UWP) por $1500. Por fim, tem a opção “super master blaster” onde você compra todos os componentes possíveis da DevExpress (inclusive os componentes para HTML5 e JavaScript) pela bagatela de $2200.

Link: http://www.devexpress.com/

Fundada em: 1998

Versão Trial: 30 dias

Telerik

A Telerik é a empresa mais conhecida no meio dos desenvolvedores, uma vez que ela costuma patrocinar diversos eventos e ações da comunidade. Por exemplo, a Telerik foi patrocinadora do podcast .NET Rocks por anos e anos (hoje em dia, ironicamente, é a DevExpress que patrocina). Eu até tenho um bonequinho ninja da Telerik na minha mesa da empresa, que eu ganhei no primeiro TechEd que eu participei (a Telerik normalmente tinha estandes e patrocinava esse tipo de evento).

Um dos componentes mais conhecidos da Telerik é o seu grid, que é tão poderoso quanto o da DevExpress:

Além disso, o pacote de componentes da Telerik também conta com diversos outros controles bem interessantes, como gráficos, editor RichText, controle visualizador de PDF, etc. As plataformas suportadas também vão desde o Windows Forms até o UWP, passando por WPF, ASP.NET e Xamarin:

E o preço? No momento da escrita deste artigo (fevereiro de 2017), plataformas separadas estão saindo entre $400 e $1000, também com updates e suporte por 1 ano. Já a opção com todas as plataformas (tirando Xamarin) sai por $1500 e o pacote completo custa $2200.

Link: http://www.telerik.com/

Fundada em: 2002

Versão Trial: 30 dias

Infragistics

Confesso a você que logo quando eu comecei a participar de eventos da comunidade (lá por volta de 2004, 2005) eu ouvi bastante o nome “Infragistics“, mas nunca tive curiosidade sequer de procurar o que isso queria dizer. Eu tenho a impressão que as pessoas sempre reclamavam da Infragistics, mas pode ser que eu esteja errado. Com o passar dos anos eu acabei descobrindo que a Infragistics era, na verdade, mais uma empresa que desenvolvia componentes para auxiliar no desenvolvimento de aplicações.

Alguns projetos legados aqui na empresa onde eu trabalho utilizam controles da Infragistics, principalmente o grid:

Assim como as outras empresas apresentadas neste artigo, a Infragitics também suporta uma variedade de plataformas, como Windows Forms, WPF, ASP.NET, Xamarin e UWP:

Componentes de uma plataforma específica custam, no momento da escrita deste artigo (fevereiro de 2017), entre $500 e $900. Já o pacote com os componentes para todas as plataformas sai por $1500.

Link: http://www.infragistics.com/

Fundada em: 1989

Versão Trial: 30 dias

ComponentOne

Eu confesso que tive pouca experiência com os controles da ComponentOne, mas dentre as quatro opções apresentadas neste artigo, ela parece ser a menos robusta. No passado eu cheguei a utilizar de leve os componentes de acesso a dados da ComponentOne, que permitiam o compartilhamento “fácil” de schemas de bancos de dados diferentes. Isso é primordial caso a sua aplicação tenha que rodar apontando para bancos de dados diferentes (como SQL Server e Oracle, por exemplo).

Dando uma olhada nas imagens de exemplo dos controles da ComponentOne, já dá para perceber que ele fica em uma categoria um pouco inferior quando comparamos com os controles da DevExpress, Telerik ou Infragistics. Por exemplo, veja só o grid da ComponentOne:

As plataformas suportadas são basicamente as mesmas das outras empresas:

Eu imaginei que os preços da ComponentOne seriam menores, mas não, eles ficam na casa de $900 a $1100. Existe um combo de componentes .NET desktop + web que sai por $1500 e um outro combo que inclui também os componentes HTML5, JavaScript e desenvolvimento móvel por $2000.

Link: http://www.componentone.com/

Fundada em: 2000

Versão Trial: 30 dias

SyncFusion

Depois de publicar e divulgar este post, diversas pessoas vieram me lembrar nos comentários sobre os controles da SyncFusion. Eu realmente tinha esquecido deles. E olha que nós usamos os ícones “metro style” da SyncFusion em um dos nossos aplicativos aqui na empresa onde eu trabalho.

A qualidade dos controles da SyncFusion é muito boa, compatível com a qualidade das outras bibliotecas apresentadas anteriormente neste artigo. Veja só um exemplo do grid da SyncFusion:

Aqui vai uma lista das plataformas suportadas atualmente:

O grande diferencial da SyncFusion é que ela possui uma edição gratuita “Community“, igual o Visual Studio. A edição é totalmente gratuita para desenvolvedores individuais e empresas que faturem menos de $1 milhão por ano. Além disso, ela oferece também as edições comerciais, que custam atualmente em média $1000 por plataforma ou $4000 para todas as plataformas.

Link: http://www.syncfusion.com/

Fundada em: 2001

Versão Trial: 30 dias

Versão Community: gratuita para desenvolvedores individuais ou empresas com faturamento até $1 milhão por ano

Concluindo

A grande mensagem que eu quero passar com este artigo é: se a sua aplicação tem uma demanda por controles complexos, não reinvente a roda! Existem diversas empresas que desenvolvem controles comerciais que podemos utilizar nas nossas aplicações, como as quatro que eu apresentei neste artigo.

Não importa qual delas você escolha, o que importa é que você não fique perdendo tempo e dinheiro desenvolvendo controles por conta própria. Faça uso desses excelentes controles desenvolvidos por terceiros, que contam com suporte e atualizações constantes.

Vamos fazer uma conta rápida aqui? Imagine que você tenha um desenvolvedor ganhando R$3000 por mês na sua empresa. Aí você pega esse funcionário e coloca ele para desenvolver uma funcionalidade extra no controle de grid do .NET. Se esse desenvolvedor trabalhar duas semanas e meia no desenvolvimento e suporte desse grid, o custo sairia basicamente o mesmo se você tivesse pago os $600, que é o que custa em média o pacote de controles para uma única plataforma das empresas abordadas nesse artigo. Não precisa nem falar o que compensa mais, não é mesmo?

Se você ainda não utiliza esses tipos de controles nos seus projetos ou na sua empresa, faça o download das versões trial, teste e veja você mesmo a quantidade de tempo que a sua empresa conseguiria reduzir no desenvolvimento das suas aplicações. Depois volta aqui e fala pra gente os resultados na caixa de comentários. E se você já utiliza ou utilizou esses ou outros componentes pagos nas suas aplicações, conta pra gente como é que foi a sua experiência também.

Por fim, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário logo abaixo.

Aplicações Android com Xamarin – Parte 2 de N – Ambiente Xamarin Android e Hello World

Por André Lima em 07/06/2017.

Dando continuidade à minha série sobre desenvolvimento Android com Xamarin, no artigo de hoje nós vamos ver como preparar o nosso ambiente Xamarin Android e publicaremos um “Hello World” no emulador.

Já era de se esperar que eu encontraria algum problema na preparação do ambiente, visto que eu já vi inúmeras pessoas descrevendo os mais diversos problemas na hora de instalar o Xamarin. Inclusive, o William Rodriguez preparou um artigo detalhando os principais problemas encontrados na instalação do ambiente Xamarin Android, porém, o problema que eu tive não fazia parte desse artigo, então tive que lutar aqui mesmo para conseguir fazer funcionar.

Acesse os artigos anteriores

Antes de continuar com a leitura deste artigo, acesse os artigos anteriores dessa série utilizando os links abaixo:

– Parte 1: Prototipando a aplicação

Primeira tentativa – Habilitando Xamarin na instalação do Visual Studio

No meu computador principal, eu tenho o Visual Studio 2015 Enterprise instalado, mas não se preocupe se você está utilizando o Visual Studio Community. O Xamarin suporta todas as edições do Visual Studio 2015 e 2017, além das versões não Express do Visual Studio 2013 (a partir do Update 2). Veja uma lista completa dos requisitos mínimos do Xamarin neste link.

Como eu não estava querendo instalar o Visual Studio 2017 nesse computador (nem tinha espaço disponível para isso), resolvi seguir com o Visual Studio 2015 mesmo. Pelo que andei lendo na internet, o passo-a-passo da instalação é idêntico tanto para o Visual Studio 2015 quanto para o 2017.

Primeiramente, eu não lembrava se eu já marcado para instalar o Xamarin quando eu instalei o Visual Studio. Para checar se eu tinha instalado ou não, eu simplesmente tentei criar um novo projeto do tipo “Android“. Se a seção “Android” da sua janela de “New Project” estiver parecida com a imagem abaixo, isso significa que você ainda não instalou o Xamarin no seu Visual Studio:

Ao utilizarmos a opção “Build native Android apps in C#“, o Visual Studio nos mostrará a seguinte página:

Se clicarmos no link “Download Xamarin“, nós cairemos em uma página onde teremos que cadastrar o nosso nome e e-mail para baixarmos a instalação do Xamarin para Visual Studio:

Porém, eu me lembro de ter visto em algum lugar que essa etapa não era mais necessária (desde que a Microsoft comprou a Xamarin e tornou a ferramenta gratuita). Foi aí que eu encontrei um guia bem completo na documentação da própria Xamarin, mostrando como instalar o Xamarin Android no Visual Studio. Foram os passos desse guia que eu segui nessa minha primeira tentativa.

No painel de controle, fui até o item “Microsoft Visual Studio Enterprise 2015 with Updates” e cliquei em “Change“:

Na janela que se abriu, escolhi a opção “Modify“:

Em seguida, marquei o item “C#/.NET (Xamarin v4.2.1)” dentro da categoria “Cross Platform Mobile Development“:

Note que, ao selecionar esse item, algumas outras opções são automaticamente checadas:

Se você ainda não tiver instalado o Visual Studio 2015 no seu computador, não se esqueça de marcar esses itens na hora da instalação do Visual Studio se você quiser trabalhar com Xamarin. Como eu ainda não tinha instalado eu tive que alterar a instalação através do Painel de Controle.

Teoricamente, ao seguirmos esses passos, o ambiente Xamarin Android deveria ter sido instalado com sucesso. Porém, como raramente as coisas funcionam corretamente logo de primeira, eu recebi um erro na instalação:

Pensei que pudesse ter acontecido algum erro de conexão, então tentei reiniciar o computador e marquei novamente esses dois itens que tinham faltado. Porém, acabei recebendo o mesmo erro.

Como sou brasileiro e não desisto nunca, abri o Visual Studio mesmo assim e tentei criar um novo projeto Android. Fiquei animado, porque agora as opções de projetos Android estavam aparecendo no meu Visual Studio:

O projeto foi criado com sucesso, porém, quando tentei compilar, recebi os seguintes erros:

Parece que o setup do Visual Studio realmente não conseguiu instalar o Android SDK no meu computador. E agora? Tentei abrir o Android SDK Manager pelo menu “Tools => Android“, mas ele nem deu sinal de vida:

Segunda tentativa – Android Studio

Pela mensagem de erro que o Visual Studio apresentou na hora de tentar compilar o projeto, aparentemente o Visual Studio não conseguiu instalar o SDK do Android e o JDK (Java Development Kit). Agora fica a dúvida: era para o setup do Visual Studio realmente ter instalado esses componentes ao ativar o Xamarin ou isso era minha responsabilidade? Enfim, de qualquer maneira, resolvi procurar a instalação do Android SDK.

Ao fazer uma pesquisa pelo Android SDK, a única coisa que eu achei foi na verdade o Android Studio. Parece que o Google não disponibiliza mais o SDK separadamente para download, mas somente em conjunto com o Android Studio, que é a IDE “oficial” de desenvolvimento para Android. De acordo com as instruções da página de download, a versão completa do Android Studio já vem com a última versão do Android SDK e do JDK.

Depois de muitos gigas baixados e instalados, encontrei esta thread no StackOverflow que mostra como descobrir os caminhos do Android SDK e JDK que estão sendo utilizados pelo Android Studio. No meu caso, os caminhos (instalação padrão) eram:

JDK – “C:\Program Files\Android\Android Studio\jre“
SDK – “C:\Users\MEUUSUARIO\AppData\Local\Android\Sdk”

Com esses caminhos em mãos, abri novamente o Visual Studio, fui até a tela “Tools => Options” e, dentro da categoria “Xamarin => Android Settings” vi que os caminhos do JDK e Android SDK estavam acusando erros:

Nota: na imagem acima só está acusando erro no JDK. É que eu esqueci de tirar um screenshot da situação original, mas no meu caso ele estava acusando erro no Android SDK também.

Clicando no botão “Change” e configurando os caminhos seguindo as informações do Android Studio, o Visual Studio parou de acusar erros:

Ao ver os dois ícones verdes no lado dos caminhos, eu fiquei animado. Será que esse era o problema da minha instalação? Será que eu conseguiria compilar o projeto?

Reiniciei o Visual Studio e tentei compilar o projeto novamente. Dessa vez o erro foi diferente:

Terceira tentativa – Instalando JDK e Android SDK “na mão”

Sem saber o que fazer para conseguir resolver essa situação, resolvi baixar o JDK manualmente no site da Oracle, utilizando o link indicado pelo Visual Studio na hora da compilação. Depois de baixar e instalar o JDK, configurei o caminho nas opções do Visual Studio, porém, a compilação do projeto ainda estava apresentando o mesmo erro.

Entretanto, algo que eu não conseguia fazer anteriormente e que agora passou a funcionar é o Android SDK Manager. Através do menu “Tools => Android => Android SDK Manager“, eu finalmente consegui abrir a bendita aplicação onde eu conseguiria escolher os SDKs do Android que deverão ser baixados!

E aí veio a dúvida: qual SDK baixar? Tomando como base a mensagem de erro apresentada pelo Visual Studio durante a instalação do Xamarin, resolvi marcar as APIs 19, 21 e 23, desmarcando a 25 que tinha vindo selecionada por padrão:

Em seguida, cliquei em “Install 40 packages” e recebi o seguinte erro:

Parece que o instalador não estava conseguindo criar os diretórios temporários porque estava faltando permissões. Reiniciei o Visual Studio como administrador, tentei novamente e, finalmente, os SDKs começaram a baixar! Uma vez concluído o download, configurei dessa maneira os caminhos nas opções do Xamarin Android:

Reiniciei o Visual Studio e, enfim, consegui compilar o projeto:

Será que eu consigo rodar esse projeto no emulador? Tentei executar o projeto e recebi algumas mensagens. A primeira delas foi sobre a utilização da internet no emulador:

Cliquei em “Yes” e recebi a segunda mensagem, que dizia que o emulador precisava rodar no modo elevado, porque ele precisava alterar algumas configurações no Hyper-V:

Clicando em “Retry“, o emulador do Android começou a carregar e, depois de alguns minutos (a primeira execução do emulador sempre é demorada), a aplicação foi executada:

Concluindo

O objetivo do artigo de hoje era mostrar a preparação do ambiente Xamarin Android para conseguirmos iniciar o desenvolvimento do nosso aplicativo. Depois de muitos problemas, eu finalmente consegui preparar o meu ambiente. Se você encontrar algum outro problema na hora da instalação, tente dar uma olhada no artigo do William Rodriguez sobre os principais problemas na instalação do Xamarin Android. Caso você não conseguir resolver, deixa um comentário que eu tento te ajudar.

E você, já preparou o seu ambiente Xamarin Android? Enfrentou algum problema durante a instalação ou você teve sorte e a instalação funcionou de primeira? Deixe o seu comentário logo abaixo contando as suas experiências na instalação do ambiente Xamarin.

Por fim, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário logo abaixo.

Até a próxima!

André Lima

Blog Lambda3 - Como usar NuGet sem escancarar a rede?

por Igor Abade | jan 31, 2017 | ALM 

Mais um post da série “causos de ALM nos cliente Lambda3“.

De um lado, os desenvolvedores querendo ter acesso irrestrito ao NuGet (www.nuget.org) por razões óbvias. De outro lado, o pessoal responsável por segurança e infraestrutura preocupados com o risco de liberar o acesso irrestrito ao NuGet no firewall.

#comofaz?

O problema

O grande desafio encontrado neste caso – que, aliás, é comum à maioria de nossos clientes – é como equilibrar entre a conveniência para os desenvolvedores e a segurança para a empresa?

Mais especificamente: a política de firewall da empresa em questão prevê, entre outras coisas, whitelisting de IPs que podem ser acessados a partir de sua rede interna. Em outras palavras, é preciso liberar um determinado range de IPs para que eles possam ser acessados.

Entretanto, em tempos de cloud computing e de endereços IPv4 esgotados, está cada vez difícil sustentar esta estratégia. Isso porque é cada vez mais comum que provedores de serviço mudem os IPs de seus serviços com uma certa frequência, contando com os serviços de DNS para notificar os clientes quando tais mudanças acontecem.

No caso do NuGet, isso quer dizer que os IPs dos endpoints de serviço do NuGet podem mudar. Veja o resultado atual (consultado no dia da publicação deste post) do DNS lookup para um dos domínios do NuGet:

C:\> nslookup api.nuget.org

Server:   ***************
Address:  ***.***.***.***

Non-authoritative answer:
Name:    cs9.wpc.v0cdn.net
Addresses:  2606:2800:157:1508:1539:174:1a75:1191
          192.16.48.200
Aliases:  api.nuget.org
          db16.wpc.azureedge.net

Viu como o domínio api.nuget.org é, na verdade, um alias (ou CNAME) para um CDN? Isso quer dizer que não há nenhuma garantia de que o IP retornado por api.nuget.org vai ser sempre 192.16.48.200. Pelo contrário – a natureza dinâmica dos CDN é quase uma certeza de que esse IP vai mudar em algum momento.

Portanto, uma liberação baseada em IPs não resolve. Neste caso, qual a alternativa?

Soluções

Obviamente precisamos de uma alternativa. Principalmente porque, no caso deste cliente, ele nos perguntou explicitamente:

Como outros clientes de você atuam nesta situação?

Bem, deixe-me compartilhar com vocês o que andamos vendo em nossos clientes:

Acesso irrestrito a *.nuget.org

Sim, é claro que esta é uma opção válida – ainda que pouco desejável em muitos de nossos clientes, que ficam desconfortáveis com acesso irrestrito à internet. Entretanto, esta é uma opção relativamente comum, em especial naqueles clientes que não podem (ou não querem) ter o overhead de gerenciar o acesso ao NuGet. Afinal, limitações de acesso aqui podem impactar diretamente na produtividade dos desenvolvedores.

Se você não se quiser liberar todos os domínios abaixo de nuget.org (*.nuget.org), pode liberar apenas estes dois:

• www.nuget.org (HTTP, HTTPS);
• api.nuget.org (HTTP, HTTPS).

O maior inconveniente dessa abordagem (segundo alguns de nossos clientes) é que o acesso precisa ser dado para todo mundo: desenvolvedores, agentes de build e release, servidores… Todo mundo pode precisar acessar o NuGet.org.

Será que não tem um meio-termo?

Servidor proxy de NuGet

Sim, há um meio-termo. Com um servidor de proxy de NuGet (usamos o ProGet em alguns de nossos clientes), não há a necessidade de liberar o acesso ao NuGet.org para todo mundo. Apenas o servidor de ProGet precisa ter acesso irrestrito ao NuGet.org.

Quando você configura um servidor ProGet interno, ele é quem baixa os pacotes do NuGet.org para você – por isso é que ele é um “proxy” do NuGet. Isso implica em uma mudança na configuração do NuGet na máquina dos desenvolvedores.

No Visual Studio de cada desenvolvedor, vá em Tools | Options, selecione a página Package Sources da configuração do NuGet e faça duas coisas:

• Inclua o endereço do feed do seu proxy (http://proget/nuget/default no meu exemplo); e
• Desabilite os outros feeds de acesso ao NuGet público.

Caso você queira evitar de fazer esse processo de configração “na mão”, pode ao invés disso atualizar o arquivo de configuração do NuGet de cada desenvolvedor (por padrão, fica em C:\Users\<nome do usuário>\AppData\Roaming\NuGet\nuget.config), seguindo o exemplo abaixo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="Package source" value="http://proget/nuget/default" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <disabledPackageSources>
    <add key="nuget.org" value="true" />
    <add key="Microsoft and .NET" value="true" />
    <add key="Microsoft Visual Studio Offline Packages" value="true" />
  </disabledPackageSources>
</configuration>

Um benefício adicional, do ponto de vista de segurança, é que o ProGet permite fazer a “curadoria” dos pacotes – ou seja, é possível aprovar/reprovar pacotes que aparecem à disposição dos desenvolvedores. Com isso, as empresas acabam com uma alternativa ainda mais segura: o invés de barrar/liberar o NuGet.org como um todo, podem fazer isso seletivamente – pacote a pacote, se necessário.

Importante

O recurso de proxy de feeds do ProGet não está disponível na versão gratuita. Para mais detalhes, visite http://inedo.com/proget/pricing

Liberação por IP

Bom, se ainda assim nada der certo e você precisar fazer a liberação por IP, resta um problema: Como saber se/quando os IPs do nuget.org mudaram? Uma alternativa é criar um script e executá-lo de tempos em tempos, a fim de verificar se os IPs mudaram ou não (visto que não há um feed oficial com essa finalidade).

Como ponto de partida, você pode dar uma olhada nest Gist. Ele tem uma função chamada Resolve-ServerAddressque recebe um FQDN como parâmetro e retorna seu IP atual, indicando se ele mudou desde a última execução. Em caso positivo, você poderia por exemplo enviar um email para um administrador avisando da mudança, a fim de que ele possa reconfigurar as regras de firewall. Daí, basta agendar sua execução (via Agendador de Tarefas do Windows) e pronto!

Passando a régua

NuGet é algo que veio para resolver um monte de problemas no ecossistema .NET – mas, como qualquer mudança de paradigma, traz seus próprios desafios. Achar o ponto de equilíbrio entre a conveniência desejada pelos desenvolvedores e a segurança necessária para a infraestrutura da empresa não é fácil, mas não dá para empurrar com a barriga. Sem resolver esse tipo de questão, não faz o menor sentido começar a discutir DevOps e assuntos correlatos.

E aí, o que achou? Deixe seus comentários!

Um abraço,
Igor

(Cross-post de http://www.tshooter.com.br/2017/01/27/como-usar-nuget-sem-escancarar-rede/)