#DevOps – WebSites, Azure and Error: Multiple types were found that match the controller named ‘messages’.

Hi!

I’ll leave it written down in a post so I will not forget later. Let’s start with the context

  • We work with a web App. For example, a Microsoft Bot App with Visual Studio
  • The deployment of it is done to Azure as part of an automated process (DevOps rules!)
  • Everything works perfectly

Until in a moment you find that your Web App does not work anymore. And when you try to navigate one of the controllers, a message like the following may appear

Multiple types were found that match the controller named ‘messages’. This can happen if the route that services this request (‘api/{controller}/{id}’) found multiple controllers defined with the same name but differing namespaces …

There are several reasons why this usually happens. However, one of the most popular is that you have renamed or changed some namespaces and new Dlls have been generated as part of the solution. The problem is that, by default, and as a mechanism to save processing time, the deployments only copy the assemblies that have been modified to the destination location. In this case, to an IIS folder, so a mix of files is in the bin folder.

Before continuing I have to take up the words of the great  Damian Brady (@damovisa):

Friends don’t let friends right-click publish

The first time you have seen an option that allows you to clean the destination directory and then copy the compilation directory is in the Publish option of a website in Visual Studio 2017

I1

Well, if you have configured the publication of your website as part of a Build – Releases process, it is in this last section that you will find the option [Remove additional files at destination], which will eliminate the unnecessary Assemblies of your solution.

I2

Happy Coding!

Greetings @ Toronto

El Bruno

Advertisements

#DevOps – WebSites, Azure y multiples controllers. Error: Multiple types were found that match the controller named ‘messages’.

Buenas!

Lo voy a dejar apuntado en un post para que luego no me olvide. Comencemos por el contexto

  • Trabajamos con una App web. Por ejemplo, una Microsoft Bot App con Visual Studio
  • El despliegue de la misma se realiza a Azure como parte de un proceso automatizado (DevOps rules!)
  • Todo funciona perfectamente

Hasta que en un momento te encuentras que tu Web App no funciona más. Y cuando intentas navegar uno de los controllers, puede aparecer un mensaje como el siguiente

Multiple types were found that match the controller named ‘messages’. This can happen if the route that services this request (‘api/{controller}/{id}’) found multiple controllers defined with the same name but differing namespaces …

Hay varios motivos por los que suele suceder esto. Sin embargo uno de los mas populares es que has renombrado o cambiado algunos namespaces y se han generado nuevas Dlls como parte de la solución. El problema está en que, por defecto, y como mecanismo para ahorrar trabajo, los despliegues solo copian los ensamblados que se han modificado a la ubicación de destino. En este caso, a un folder de IIS.

Antes de seguir tengo que retomar las palabras del gran Damian Brady (@damovisa):

Friends don’t let friends right-click publish

La 1ra vez que has visto una opción que te permite limpiar el directorio de destino y luego copiar el directorio de compilación es en la opción Publish de un website en Visual Studio 2017

I1

Pues bien, si has configurado la publicación de tu website como parte de un proceso de Build – Releases, es en esta última sección donde encontraras la opción [Remove additional files at destination], que eliminara los Assemblies innecesarios de tu solución

I2

Happy Coding!

Saludos @ Burlington

El Bruno

#Event – #DevOps Lessons learned and some information on the #Hololens Tour on June

giphy
Hello!

During these days in Visual Studio Live @ Austin I have been lucky enough to go to a lot of very good sessions. In example, I’ve seen how Brian Randell or Richard Hundhausen made great DevOps demos concepts using Visual Studio Team Services. I liked a lot how now, when we use Team Foundation in the Cloud, it allows us to explain DevOps concepts almost instantaneously.

This makes me remember my ALM sessions 10 years ago. In those days, we made the first demos of TFS 2005 or 2008 and had to deal with resources for everything. On the one hand I needed a powerful laptop, because usually the demo was running in a virtual machine. There were even more complex scenarios where in addition to the TFS VM, I needed another virtual machine for a Domain Server, another VM for SharePoint, and maybe a couple more.

In those days, I remember that as we needed power, we used to have very big laptops. In my case, I used to travel with one or more external disks where I got “my demo VMs”. And, of course, well the experience of assembly and preparation before an event was not easy at all. I will not deny it, they were moments of many nerves, and also of instant gratification when at the end of the session you received a question related to the topic of the event.

These days I have to deal with something similar, Hololens sessions. Everything seems easy when we watch Build or another big event mixed reality sessions. However, in technical sessions we usually may deal with

  • The need for a very powerful laptop. Mostly to be able to use Visual Studio and Unity3D in a comfortable way. This is going back to traveling with big laptops which are usually bigger than an airplane suitcase
  • The complicated development flow for this type of projects. At minimum we need one instance of Unity3D, and 2 Visual Studio instances
  • The compilation dead times we have for and App or the long deploy times to deploy an App to a device
  • The delay we have when the FOV of Hololens is presented. Delay between what the user of Hololens actually sees and what is projected from an external computer.

And finally

  • The low sense of immersion of the audience when viewing a 2D projection on a projector or similar. When the real experience is lived by the person who is using the HoloLens

While there are some workaround for some topics, such as to improve projection delay, the ideal is to think of the session in a different way. In one year with more than 20 Hololens sessions for groups of users and clients, I have learned to review these points when I prepare a session:

  • Based on the time of the session, create a suitable script for the time and content to show. For example, if the session is a session for programmers, it is best to plan a demo moment with a live debugging of an App from Hololens to Visual Studio
  • If the session allows you, perform “Live Code”. In this type of example, where a simple Hello world can take a long time to create from scratch, it is best to have 90% of the project/code complete and only add the missing parts live.
  • Avoid App deployment times to device. A built and deployed App saves a few valuable minutes in the session

And finally not forgetting the basics

  • Review and know in advance the place where the session will be held. It is important to note that Hololens demos need space for the holograms, an adequate light level and also a good Internet connection

I will take all of this in mind for the future Hololens Tour in the month of June, where I’ll be lucky enough to talk about Hololens in the .Net User Groups in Mississauga, Toronto and London. In addition, I am preparing some special surprises for these events, which I will communicate as soon as I can confirm them.

The last days of June will be fun!

Greetings @ Austin

El Bruno

#Event – Lecciones aprendidas de #DevOps y el próximo #Hololens Tour en Junio

giphy

Hola !

Durante estos días en Visual Studio Live @ Austin he tenido la suerte de participar en muchas sesiones que han sido magistrales. He visto como Brian Randell o Richard Hundhausen hacían grandes demos de conceptos de DevOps utilizando Visual Studio Team Services. Me gustó mucho como ahora, el uso de Team Foundation en el Cloud, nos permite explicar conceptos de DevOps de forma casi instantánea.

No pude más que acordarme de mis sesiones 10 años atrás. En esos días, hacíamos las primeras demos de TFS 2005 o 2008 y había que tener recursos para todo. Por un lado necesitabas un laptop potente, porque por lo general la demo era sobre una máquina virtual. Inclusive había escenarios más complejos donde además de una VM para el TFS, era necesaria otra máquina virtual como servidor de dominio, otra máquina virtual para Sharepoint, y tal vez un par más.

En esos días, recuerdo que como necesitábamos potencia, siempre los laptops que úsabamos eran “grandes”. En mi caso, solía viajar con uno o más discos externos donde “vivían mis VMs” y, bueno la experiencia de montado y preparación antes de un evento no era para nada fácil. No voy a negarlo, eran momentos de muchos nervios, y también de gratificación instantánea cuando al final de la sesión recibias una pregunta relacionada con el tema del evento.

En estos días me toca lidiar con algo parecido que son las sesiones con Hololens. Todo parece fácil cuando vemos las sesiones de Mixed Reality de eventos como Build. Sin embargo, en sesiones técnicas nos encontramos con problemas como

  • La necesidad de un laptop muy potente para poder utilizar Visual Studio y Unity3D de una forma decente. Esto es volver a viajar con laptops que suelen pesar más que una maleta de avión
  • El flujo complicado de desarrollo que se presenta para este tipo de proyectos con mínimo una instancia de Unity3D, y 2 de Visual Studio
  • Los tiempos muertos que hay cuando se compila una App o se despliega a un device
  • El lag que hay cuando se presenta el FOV de Hololens. Delay entre lo que realmente ve el usuario de Hololens y lo que se proyecta desde un ordenador externo.

Y finalmente

  • La escasa sensación de inmersion del público al ver una proyección en 2D en un proyector o similar. Cuando la verdadera experiencia la vive la persona que está utilizando las Hololens

Si bien hay algunos workaroung para algunos temas, como por ejemplo para mejorar el delay de proyección, lo ideal es pensar en la sesión de una forma diferente. En un año con más de 20 sesiones de Hololens en grupos de usuarios y clientes de Avanade, he aprendido a repasar estos puntos cuando preparo  una sesión:

  • En base al tiempo de la sesion, crear un guión adecuado para el tiempo y el contenido a mostrar. Por ejemplo, si la sesión es una sesión para programadores, lo mejor es tener planificado un momento de demo con una depuración en vivo de una app desde Hololens a Visual Studio
  • Si la sesión lo permite realizar “live code”. En este tipo de ejemplos, donde un simple Hola Mundo puede tardar bastante tiempo en crearse desde cero, lo mejor es tener el 90% del proyecto / código completo y solo agregar las partes que faltan en vivo.
  • Evitar tiempos de despliegue de Apps al device. Una app compilada y desplegada, ahorra unos minutos valiosos en la sesión

Y finalmente no olvidar de los básicos

  • Revisar y conocer de antemano el sitio donde se hará la sesión. Es importante tener en cuenta que las demos de Hololens necesitan espacio para los hologramas, un nivel de luz adecuado y también una buena conexión a internet

Todo esto lo tendré en cuenta para el futuro Hololens Tour en el mes de Junio, donde tendré la suerte de hablar de Hololens en los grupos de usuarios de .Net en Mississauga, Toronto y London. Además, estoy preparando algunas sorpresas especiales para estos eventos, que las comunicaré en cuanto pueda confirmarlas.

Los últimos días de Junio serán divertidos a más no poder!

Saludos @ Austin

El Bruno

#Hololens – About DevOps, ALM and #Unity3D

Hello.

When you start to work on a Hololens project, one of the first things you learn is “Unity3D is different“. Besides the graphical aspects and the paradigm shift, there is an important point to keep in mind.

 

Even if a Unity project is a collection of files, you can’t go with something easy as control all those files with a version control system (in example, TFVC or Git). In order to take control over the complete lifecycle in a project-oriented way, you need to consider some special nuances.

As well, I’ve been learning in baby steps mode. The truth is it has been an interesting experience. The use of tools like Visual Studio Tools for Unity, made much easier to transfer some the knowledge we already have working with Visual Studio, to the Unity3D environment. However, you can also go one step further. And here it is essential to read this MSDN article, Application Lifecycle Management (ALM) with Unity Apps.

This article describes some detailes insights on the wollowing topics on the use of Unity and Team Foundation or Team Services tools:

  • Agile Tools
  • Modeling
  • Code
  • Build
  • Testing
  • Improve Code Quality
  • Release Management
  • Monitor with HockeyApp (sigh!)

Sections like versioning files, details on how Unity works different and the best thing is to read some official documentation of Unity: Using External Version Control Systems with Unity. Another similar scenario, is that arises with the compilation, where the recommendation is to automate the collection and generation of packages using command line MSBuild.

The truth is that it is a document to take into account and a good basis to know what we need if we want to create quality with Unity3D and Visual Studio apps.

Greetings @ Toronto

El Bruno

References

#Hololens – Sobre DevOps, ALM y #Unity3D

Hola.

Cuando comienzas a trabajar en un proyecto para Hololens, una de las primeras cosas que aprendes es que “Unity3D es diferente”. Además de los aspectos gráficos y del cambio de paradigma, hay un punto importante a tener en cuenta.

Si bien un proyecto de Unity es una colección de archivos, la solución no es tan simple como controlar TODOS con un sistema de versionado de archivos (TFVC o GIT, por ejemplo). Tener un control sobre el ciclo de vida de los mismos, orientados a proyecto, requiere algunas sutilezas especiales a tener en cuenta.

Pues bien, yo he ido aprendiendo a tropezones. Y la verdad es que ha sido una experiencia interesante. Herramientas como Visual Studio Tools for Unity hacen que muchos de los conocimientos que ya poseemos trabajando con Visual Studio, puedan ser fácilmente traspasados a Unity3D. Sin embargo, también puedes dar un paso más. Y aquí es fundamental leer este artículo de MSDN, Application Lifecycle Management (ALM) with Unity Apps.

En el mismo se realiza un recorrido sobre el soporte en Unity de herramientas de Team Foundation o Team Services en los apartados

  • Agile Tools
  • Modeling
  • Code
  • Build
  • Testing
  • Improve Code Quality
  • Release Management
  • Monitor with HockeyApp (sigh!)

Lo interesante, es que en apartados como por ejemplo el control de archivos, se nos explica que Unity trabaja diferente y que lo mejor es leer un poco de documentación oficial de Unity: Using External Version Control Systems with Unity. Otro escenario similar, es el que se presenta con la compilación, donde la recomendación va por automatizar la compilación y generación de paquetes utilizando command line en MSBuild.

La verdad es que es un documento a tener en cuenta y una buena base para saber lo que necesitamos si queremos crear apps de Calidad con Unity3D y Visual Studio.

Saludos @ Toronto

El Bruno

References