Neste post vou explicar como fazer para o .NET Core compilar uma aplicação em um runtime específico detalhando os runtimes desejados no project.json.

Em um post anterior (Criando um projeto .NET Core usando a linha de comando e o Visual Studio Code) eu expliquei como criar uma aplicação simples. Vou usar esse mesmo projeto neste post.

Ao abrir o arquivo project.json temos a seguinte configuração:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.0.1"
        }
      },
      "imports": "dnxcore50"
    }
  }
}

Para uma aplicação .NET Core em um runtime específico devemos remover o atributo “type”: “platform” das dependences dentro das especificações dos frameworks, neste caso, netcoreapp1.0.

Nesse projeto só é preciso fazer isso na dependência Microsoft.NETCore.App. O atributo vai ficar como o código abaixo.

        "Microsoft.NETCore.App": {
          "version": "1.0.1"
        }

O próximo passo é adicionar o atributo runtimes ao arquivo project.json. O atributo runtimes define para quais runtimes o projeto deve ser compilado. A documentação oficial possui uma lista de runtimes disponíveis através da explicação do .NET Core Runtime IDentifier (RID).

Neste caso, vou usar o Windows 10. Para isso é preciso informar no arquivo project.json o identificador do runtime desejado como win10-x64.

Por fim, o arquivo project.json vai ficar da seguinte maneira:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1"
        }
      },
      "imports": "dnxcore50"
    }
  },
  "runtimes": {
    "win10-x64": {}
  }
}

Agora, ao usar o comando dotnet restore seguido do dotnet build a compilação gerada será especificamente para Windows 10 e estará no caminho \bin\Debug\netcoreapp1.0\win10-x64.

Quando o projeto é compilado para um runtime específico ele possibilita usar o comando dotnet publish. Ele copia o executável, as DLLs e o framework para um diretório publish dentro do diretório do runtime especificado. Neste caso, \bin\Debug\netcoreapp1.0\win10-x64\publish.

É possível notar que agora, dentro do diretório publish, temos o nosso executável e todas as DLLs necessárias, inclusive as do .NET Core, como mostra a imagem abaixo:

Com isso feito, é possível executar a aplicação em qualquer computador com Windows 10, mesmo que ele não tenha o .NET Core instalado.

O código completo do projeto está no GitHub, basta clicar aqui para vê-lo.

Se quiserem conhecer mais sobre mim, basta ir aqui no blog no menu quem sou e conferir também o meu LinkedIn.

Se ficou alguma dúvida, comenta aqui no blog que eu tento ajudar. 🙂

 

No artigo “Criando Action Results (IHttpActionResult) personalizados no ASP .NET WEB API” aqui do blog expliquei mais detalhadamente como criar uma classe de resposta personalizada. E nesse artigo vou dar uma ideia de uma classe que se encaixa melhor no uso do dia-a-dia.

Em um exemplo mais real, podemos criar uma resposta personalizada chamada ErrorResult que retorna um HTTP status code de internal server error e um objeto de exceção contendo algumas informações padrões.

 namespace LuizPauloPradoBlog.WebApi.ActionResults
{
    public class ErrorResult : IHttpActionResult
    {
        private HttpRequestMessage _request;
        private Dictionary<string, string> _customizedException;

        public ErrorResult(HttpRequestMessage request, Exception ex)
        {
            _request = request;
            _customizedException = CreateCustomizedException(ex);
        }

        public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
        {
            var response = new HttpResponseMessage()
            {
                Content = new StringContent(JsonConvert.SerializeObject(_customizedException)),
                StatusCode = HttpStatusCode.InternalServerError
            };

            return Task.FromResult(response);
        }

        private Dictionary<string, string> CreateCustomizedException(Exception ex)
        {
            var message = ex.Message;
            var innerMessage = ex.InnerException == null ? string.Empty : ex.InnerException.Message;

            var customizedException = new Dictionary<string, string>();
            customizedException.Add("Message", message);
            customizedException.Add("InnerMessage", innerMessage);

            return customizedException;
        }
    }
}

Ao chamar a resposta de ErrorResult, é passado um objeto de Exception e dentro da classe tratamos ele para somente retornar a mensagem de erro e a mensagem de erro interna. Quando o ExecuteAsync é chamado, o nosso objeto é convertido para JSON e é retornado na reposta HTTP.

Neste caso, isso é feito para não expor todo o objeto de Exception, que pode conter informações sigilosas da aplicação.

[HttpGet]
public IHttpActionResult Get(string name)
{
    try
    {
        var item = _sampleData.Single(x => x == name);
        return Ok(item);
    }
    catch (Exception ex)
    {
        return new ErrorResult(Request, ex);
    }
}

Com isso, sempre que a controller soltar uma exceção, podemos tratá-la e retornar somente as informações relevantes para o usuário.
O código completo do projeto está no GitHub, basta clicar aqui para vê-lo.
Se quiserem conhecer mais sobre mim, basta ir aqui no blog no menu quem sou e conferir também o meu LinkedIn.

Se ficou alguma dúvida, comenta aqui no blog que eu tento ajudar. 🙂

Neste artigo vou explicar como criar um Action Result, herdado da interface IHttpActionResult , no ASP .NET WEB API.

De modo geral, a interface IHttpActionResult representa a criação de repostas HTTP na nossa controller. Ela basicamente representa uma factory de respotas HTTP usando HttpResponseMessage.

Quem quiser mais detalhes, aqui no blog tem o post para entender a diferença entre os Action Results IHttpActionResult e HttpResponseMessage que explica o assunto.

No trecho de código abaixo temos dois exemplos de tipos de respostas IHttpActionResult que geralmente são usados em métodos de controllers.

[HttpGet]
public IHttpActionResult Get()
{
    if (_sampleData == null)
        return NotFound();

    return Ok();
}

O Ok() representa uma resposta HTTP que se refere a um status code de OK. Já a resposta NotFound(), representa uma resposta  HTTP que se refere a um status code de not found.

Para criar uma resposta personalizada, precisamos criar uma classe que implemente a interface IHttpActionResult e tenha um método chamado ExecuteAsync.

namespace System.Web.Http
{
    public interface IHttpActionResult
    {
        Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken);
    }
}

O método ExecuteAsync é chamado para criar um objeto  HttpResponseMessage, que representa uma reposta HTTP dentro da nossa aplicação. Nele é possível usar todas as funções desta classe e manipular a resposta a ser criada. O retorno do método é uma Task, que quando executada, vai conter o objeto de resposta HTTP.

Para entender melhor como tudo funciona, vamos criar uma resposta de exemplo.

namespace LuizPauloPradoBlog.WebApi.ActionResults
{
    public class SampleResult : IHttpActionResult
    {
        private string _message;

        public SampleResult()
        {
            _message = "OK " + DateTime.Now.ToShortDateString();
        }

        public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
        {
            var response = new HttpResponseMessage()
            {
                Content = new StringContent(_message)
            };

            return Task.FromResult(response);
        }
    }
}

No exemplo acima foi criada uma resposta chamada SampleResponse que retorna sempre uma mensagem de OK com a data atual.

[HttpGet]
public IHttpActionResult Get()
{
    return new SampleResult();
}

Ao instanciar nosso SampleResult na controller, a classe irá internamente criar uma mensagem e executar o ExecuteAsync para criar a resposta HTTP.

O código completo do projeto está no GitHub, basta clicar aqui para vê-lo.

Se quiserem conhecer mais sobre mim, basta ir aqui no blog no menu quem sou e conferir também o meu LinkedIn.

Se ficou alguma dúvida, comenta aqui no blog que eu tento ajudar. 🙂