Msbuild não reconhece a unidade de rede mapeada

1

Temos um projeto que cria e tem um evento de pós-compilação. O evento post build compila a DLL de saída em um diretório F. O sistema deve colocar todas as DLLs na unidade F. No meu sistema, não consigo particionar minha unidade para adicionar uma unidade F, então mapeei uma pasta F falsa para ser a unidade F.

F drive -> \<PC IP>\C$\F\

Quando eu construo a solução usando o Visual Studio 2008, o evento post build é bem-sucedido. Mas quando eu tento construir a solução usando a linha de comando msbuild, ele falha e diz que a "unidade especificada não existe". Alguma idéia de como enganar o powershell para acreditar que o drive F existe? Eu posso navegar para a unidade F usando o Windows Explorer corretamente e como eu disse anteriormente, o evento de compilação de post é bem-sucedido ao usar o IDE.

A linha de comando do powershell usada:

msbuild MySolution.sln /p:Configuration=Debug /p:Platform="Any CPU"

Observe que meu sistema é um profissional do Windows 7. Eu tentei fazer o mesmo msbuild usando o Windows XP e não há problema. Eu corri o prompt de comando com direitos de administrador também.

    
por Nassign 06.03.2012 / 02:14

1 resposta

2

Se você quiser falsificar uma letra de unidade em um computador local, use SUBST em vez de mapear uma unidade de rede.

De Subst /? :

Associates a path with a drive letter.

SUBST [drive1: [drive2:]path]
SUBST drive1: /D

  drive1:        Specifies a virtual drive to which you want to assign a path.
  [drive2:]path  Specifies a physical drive and path you want to assign to
                 a virtual drive.
  /D             Deletes a substituted (virtual) drive.

Então você deve poder usar algo como c:\> subst F: C:\F .

Verifique também se está substituindo a unidade (ou mapeando-a) no mesmo espaço de usuário em que o Powershell / MSBuild está sendo executado. Se você mapear uma unidade como o usuário local e o MSBuild estiver em execução como 'Administrador' ela ganhou poderá ver sua unidade mapeada pelo usuário (e vice-versa).

    
por 06.03.2012 / 02:19