Host componente de bower en Visual Studio Online

Problema:
Lo que trato de hacer es alojar un componente de bower en Visual Studio en línea. Sin embargo, esto no parece posible de la forma en que trato de hacerlo.

Creé un componente de bower y lo registré en Visual Studio en línea con el tutorial de Brian Ford . Este componente de bower ahora reside de forma segura en mi proyecto visual git project. Sin embargo, cuando trato de hacer:

bower install https://myAccount.visualstudio.com/DefaultCollection/_git/bower-component 

pone algo en la carpeta bower_components, pero estos no son los componentes de bower que he enviado a visual studio en línea. En la carpeta bower_components hay un bower.json, con algunos valores incorrectos y un file de "índice", sin extensión de file. Cuando abro este file "index" en un editor, parece que la página de inicio de session de visual studio en línea.

Para mí, parece que el problema es la authentication cuando se conecta a Visual Studio en línea.

Lo intenté:

  • Las cnetworkingenciales de git usadas se almacenan, pero esto no parece tener ningún efecto cuando se intenta download los componentes del bower.
  • También traté de usar "private-bower" para registrar Visual Studio en línea como proxy con el nombre de usuario y la contraseña alternativos de visual studio en línea. Sin embargo, no fue posible registrar las URL de Visual Studio en línea porque private-bower solo admite git: // URL's.

¿Alguien tiene alguna experiencia tratando de hacer que esto funcione con Visual Studio en línea o con cualquier server de base de equipos? ¿O alguien tiene otras posibles soluciones a este problema?

Solutions Collecting From Web of "Host componente de bower en Visual Studio Online"

* Actualización junio de 2016

TFS 2015 (a partir de la Actualización 3) ahora admite la connection SSH a repositorys Git . El uso de git+https:// puede que ya no sea necesario para que Bower recupere el código, pero requerirá algunas testings de su parte.


Respuesta original

Me metí en esto la semana pasada e hice algunos hallazgos interesantes. Una solución alternativa y un posible error identificado en TFS. Investigué con una versión in situ de TFS, pero aún puede aplicarse.

Para empezar, querrá usar HTTPS para conectarse a su instancia de TFS. Bower, al extraer de una fuente HTTPS , pedirá las cnetworkingenciales que pasan a TFS. Entonces, dado que TFS no reconoce el sufijo " .git " que Bower también espera de un repository de Git en línea, debe ajustar el protocolo.

 bower install git+https://tfs.domain.com/tfs/Collection/_git/MyComponent 

Esto debería ser suficiente para que Bower hable con TFS y retire el componente. Tendrá que ingresar sus cnetworkingenciales mientras se ejecuta, a less que se sienta cómodo colocándolas en la URL en sí (lo que yo no haría).


Ahora, donde se encontrará con problemas es si label sus commits con versiones (como lo haría con la versión adecuada de su componente). TFS parece no jugar muy bien con las tags, como habrás notado. Si haces esto, cuando Bower ejecute un pago, se genera un error en TFS.

 InvalidCastException: Unable to cast object of type 'Microsoft.TeamFoundation.Git.Server.TfsGitTag' to type 'Microsoft.TeamFoundation.Git.Server.TfsGitCommit'. 

Encontré esto mirando los loggings de administración en http://tfs.domain.com:8080/tfs/_oi .

Si traté de pagar un componente de bower en el que no marque ninguna de mis confirmaciones, las cosas funcionaron correctamente .

Esta información también se publica en los foros de MSDN .

Parece que necesita configurar y usar cnetworkingenciales alternativas en lugar de su count normal de Microsoft. El process se explica en la publicación de Buck .

Agregar git + https funcionó para mí.

Aquí está en el bower.json:

  "dependencies": { "some-component": "git+https://domain.com/path/to/git" }