У нас есть веб-приложение, которое активно использует динамическую компиляцию кода.
У меня есть задача добавить функции C # 6 и использовать компилятор Roslyn.
Сделать это было довольно просто. Просто добавьте пакет nuget
- Microsoft.CodeDom.Providers.DotNetCompilerPlatform: 2.0.0
для всех проектов, использующих динамическую компиляцию кода и изменяющих одну строку кода
private static System.CodeDom.Compiler.CodeDomProvider Compiler => compiler
?? (compiler =
new
Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider());
Пока все работает. После добавления пакета nuget в модульные тесты, использующие динамическую компиляцию кода, они также работают (локально).
Но когда я запрашиваю новую сборку на VSTS / TFS-сервере, некоторые модульные тесты не пройдены. После некоторого исследования я нашел проблему:
System.IO.DirectoryNotFoundException: Не удалось найти часть пути 'D: \ Agents \ agent_work \ 1 \ a \ roslyn \ csc.exe'.
в System.IO .__ Error.WinIOError (Int32 errorCode, String MaybeFullPath)
at System.IO.FileStream.Init (Путь к строке, режим FileMode, доступ к FileAccess, права Int32, логическое значение useRights, общий ресурс FileShare, параметры типа3232 bufferSize, параметры FileOptions, SECURITY_ATTRIBUTES secAttrs, строка String msgPath, логическое значение bFromProxy, логическое значение useLongPath, Boolele), Boolele)
в System.IO.FileStream..ctor (путь строки, режим FileMode, доступ к FileAccess, общий доступ к FileShare)
в Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.get_CompilerName ()
в Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.FromFileBatch (параметры CompilerParameters, String [] fileNames)
в Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.FromSourceBatch (параметры CompilerParameters, источники String [])
в Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Compiler.CompileAssemblyFromSourceBatch (параметры CompilerParameters, источники String [])
в System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource (параметры CompilerParameters, источники String [])
в [...]
Ну, корень проекта - это не то место, где нужно искать исполняемые файлы.
В app.config связанных юнит-тестов:
<appSettings>
<add key="aspnet:RoslynCompilerLocation" value="roslyn" />
</appSettings>
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" />
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+" />
</compilers>
</system.codedom>
Я также пытался использовать пакет nuget Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix
без успеха. Я нашел много информации о том, как исправить ошибку / bin / roslyn, но ничего об этой специальной комбинации сервера сборки, модульных тестов и roslyn. У кого-нибудь есть дополнительная информация?
EDIT:
Я попробовал предложенное решение от Jayendran. Я обнаружил, что переменные $ (CscToolPath) и $ (WebProjectOutputDir) были пустыми, например:
<Target Name="CheckVariables" AfterTargets="AfterBuild" Condition="'$(OutDir)' != '$(OutputPath)'">
<Message Text="$(OutDir)" Importance="high"/>
<Message Text="$(OutputPath)" Importance="high"/>
<Message Text="$(CscToolPath)" Importance="high"/>
<Message Text="$(WebProjectOutputDir)" Importance="high"/>
</Target>
Не было вывода для $ (CscToolPath) и $ (WebProjectOutputDir).
EDIT2:
В качестве обходного пути я отредактировал app.configs модульных тестов так:
<appSettings>
<add key="aspnet:RoslynCompilerLocation" value="_PublishedWebsites\*OneOfTheWebApps*\bin\roslyn" />
</appSettings>
Модульные тесты теперь могут находить двоичные файлы, и кажется, что это изменение не влияет на мою локальную машину. Модульные тесты теперь проходят локально и на сервере сборки. Однако это не может быть решением этой проблемы.