Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=13.100.0.0 - visual-studio-2017

I am attempting to run a build in TFS 2018. We also have SQL Server 2016 installed on the TFS build server (which is Windows Server 2016). Visual Studio is 2017. The first solution file produces the following error, and I have no idea from where this file is referenced:
2019-01-22T20:35:26.8607312Z Package:
2019-01-22T20:35:26.8608029Z Invoking Web Deploy to generate the package with the following settings:
2019-01-22T20:35:26.8608667Z $(LocalIisVersion) is 10
2019-01-22T20:35:26.8609527Z $(DestinationIisVersion) is 10
2019-01-22T20:35:26.8610846Z $(UseIis) is True
2019-01-22T20:35:26.8612479Z $(IisUrl) is http://localhost:62327/
2019-01-22T20:35:26.8614266Z $(IncludeIisSettings) is False
2019-01-22T20:35:26.8615630Z $(_DeploymentUseIis) is False
2019-01-22T20:35:26.8617245Z $(DestinationUseIis) is False
2019-01-22T20:35:26.8666548Z GenerateMsdeployManifestFiles:
2019-01-22T20:35:26.8684620Z Generate source manifest file for Web Deploy package/publish ...
2019-01-22T20:35:27.0589951Z Visual Studio is 2017. ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Deploy\Microsoft.Web.Publishing.MSDeploy.Common.targets(119,5): Error MSB4018: The "SqlScriptPreprocessSqlVariables" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=13.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.SqlServer.BatchParser, Version=13.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
at Microsoft.Web.Publishing.Tasks.SqlScriptPreprocessor.SqlScriptPreprocessSqlVariables.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Found the same workaround that Michiel referred to.
My situation:
Visual Studio 2017 Build Tools (no IDE)
Microsoft.SqlServer.BatchParser Version=13.100.0.0 not registered in
the Global Assembly Cache. Neither was 13.0.0.0.
VS Build Tools does not include Microsoft.SqlServer.BatchParser.dll. The path referenced is for VS Enterprise and does not exist for Build Tools: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLCommon\130. There is no similar path under C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools
I checked install of Build Tools. Said that SQL Server Data Tools was installed - under Data Storage and Processing workload
My solution:
Per recommendation here, I downloaded and installed SQL Server Data Tools followed by a reboot.
That got Microsoft.SqlServer.BatchParser Version=13.0.0.0 registered in the Global Assembly Cache
Then, per workaround in question (developercommunity above), I added a binding redirect for MSBuild (in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\BinMSBuild.exe.config - see below)
Fixed.
<!-- Workaround for errorMSB4018: The "SqlScriptPreprocessSqlVariables" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=13.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified. -->
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.BatchParser" culture="neutral" publicKeyToken="89845dcd8080cc91" />
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="13.0.0.0"/>
</dependentAssembly>

Found a workaround here, for the desktop build. Did not try the TFS team build.
Use gacutil to register Microsoft.SqlServer.BatchParser v2015.130.1601.5 installed with Visual Studio 2017, apparently satisfying build task SqlScriptPreprocessSqlVariables even if it requested v13.100.0.0.
In:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions\Microsoft\SQLCommon\130
or similar issue:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools\gacutil.exe" /i Microsoft.SqlServer.BatchParser.dll
or similar.
2023-02-14 The issue occurred again, now using Visual Studio 2022. The following workaround fixed the issue.
VS2022 now runs in 64 bit. Microsoft.SqlServer.BatchParser.dll built for 64 bit should be used. Also adding assemblies to the GAC is now discouraged. Instead copy the assembly from the installation location of VS2022, for example:
C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\Extensions\Microsoft\SQLCommon\150
to the correct MSBuild folder. Several MSBuild folders may be around, use the 64 bit folder actually used by VS2022, for example:
C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64
Build task SqlScriptPreprocessor.SqlScriptPreprocessSqlVariables resides in assembly Microsoft.Web.Publishing.Tasks.dll. That assembly asks for version 13.100.0.0 of Microsoft.SqlServer.BatchParser.dll. Version 13.100.0.0 cannot be used; it results in "Invalid assembly platform or ContentType in file". Instead add an assembly redirect for MSBuild. In for example:
C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\MSBuild.exe.config
add
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.BatchParser" culture="neutral" publicKeyToken="89845dcd8080cc91" />
<bindingRedirect oldVersion="0.0.0.0-999.999.999.999" newVersion="15.100.0.0" />
</dependentAssembly>
15.100.0.0 being the assembly version of Microsoft.SqlServer.BatchParser.dll; ignore any file version such as 2018.150.1000.16.

Related

Unreal Engine 4 Basic C++ Code Project giving compile error

I have been having this a problem when loading up a "Basic C++ Code Project" and have had absolutely no success due to lack of information.
The error is as follows:
Running E:/Program Files/Epic Games/UE_4.22/Engine/Binaries/DotNET/UnrealBuildTool.exe Development Win64 -Project="D:/[My-User]/Documents/Code/[Project Root Dir]/[Project]/[Project].uproject" -TargetType=Editor -Progress -NoHotReloadFromIDE
Creating makefile for [Project]Editor (no existing makefile)
#progress push 5%
Parsing headers for [Project]Editor
Running UnrealHeaderTool "D:\[My-User]\Documents\Code\[Project Root Dir]\[Project]\[Project].uproject" "D:\[My-User]\Documents\Code\[Project Root Dir]\[Project]\Intermediate\Build\Win64\[Project]Editor\Development\[Project]Editor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -installed
Reflection code generated for [Project]Editor in 8.2032876 seconds
#progress pop
Using Visual Studio 2017 14.16.27023 toolchain (C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023) and Windows 10.0.18362.0 SDK (C:\Program Files (x86)\Windows Kits\10).
ERROR: System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at UnrealBuildTool.XGE.ExecuteTaskFile(String TaskFilePath, DataReceivedEventHandler OutputEventHandler, Int32 ActionCount) in D:\Build\++UE4\Sync\Engine\Saved\CsTools\Engine\Source\Programs\UnrealBuildTool\Executors\XGE.cs:line 493
If there is any more information relating to this problem I am happy to provide it.
There could be something wrong with your installation of visual studio. Check your Visual Studio installer and ensure that the Game development with C++ workload is ticked. I typically also install the .NET Framework 4.6.2 SDK and targeting pack under the individual components list.
In your case it seems to be looking for Visual Studio 2017, so try the steps above with 2017 first.
I had similar problem after my pc shutdown
after backing up everything I removed all folders except source, content and config than generated virtual studio files using .uproject
problem solved :)
I figured out the issue. It didn't like using UE 4.22.3 for some reason...
Thanks for the help guys!

All Unit Test projects in TeamCity does not compile failing to reference Microsoft.VisualStudio.QualityTools.UnitTestFramework

All our unit test projects (About 8 of them) just stopped compiling and I can't find any good reason for it.
"error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)"
From the TeamCity (v2017.2.2) build log the projects are missing the Microsoft.VisualStudio.QualityTools.UnitTestFramework DLL with error codes CS0234 and CS0246. I can't see any code changes that could have caused it
there was however a server restart that might have kicked in some pending changes.
What has been checked
Checked both with a Visual Studio (SLN) and MSBuild runner step, both gave the same results (MSBuild was previously working fine while the Visual Studio was failing on the C# 6/7 code, the reason why we changed to a newer MSBuild version)
These Test projects build fine on the same build server if the solution is opened in Visual Studio 2017 Enterprise (Installed on Build server)
Project Reference configuration
<Choose>
<When Condition="('$(VisualStudioVersion)' == '10.0' or '$(VisualStudioVersion)' == '') and '$(TargetFrameworkVersion)' == 'v3.5'">
<ItemGroup>
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework" />
</ItemGroup>
</Otherwise>
</Choose>
MSBuild Version
We use the MSbuild v15.6.82.30579 in Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin not the default one in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 (Added as such to environmental variables)
Any recommendations will be appreciated. I really don't want to start adding DLL's to the GAC if it can be helped.
If you are using Build Tools 2017 on your server, and you don't have Visual Studio 2017 installed, then you have to switch to MS Test v2:
https://blogs.msdn.microsoft.com/devops/2017/09/01/upgrade-to-mstest-v2/
https://www.nuget.org/packages/MSTest.TestAdapter
https://www.nuget.org/packages/MSTest.TestFramework
Old MS Test framework is not supported with Build Tools.
Then in TeamCity in Build Step you have to change your runner type to Visual Studio Tests, Test engine type from MSTest to VSTest, and Test engine Version to VSTest 2017
Install "VC++ 2017 version 15.7 v14.14 toolset" component under individual components, seems that the default toolset does not have the unit test binaries.
References:
Unit test files not installed by Visual Studio Build Tools 2017
Okay so the issue seemed to be broader than just Unit Tests. In short even though MSbuild and Visual Studio build (from the build server) running MSBuild step from Visual Studio does not utilize the same 'shared' folders.
I had to make use of a couple of different strategies to sort out version and missing common DLL's:
Update the Visual Studio Build Tools to the latest version i.e. get the latest version of MSBuild to the build server and ensure it is added to the OS environmental PATH (Set the default MSBuild to be the new one). In my case it was changing it from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319' to 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin'
Add the missing/newer DLL to the MSBuild BIN folder and mark it as read-only so that it is not overridden again
As last resort you add the DLL to the GAC using the gacutil.exe. This is not recommended because it obfuscates the relationship (Rather try to find where it is used with Fusion logging and add it there).

Visual Studio 2015 doesn't load after PC restart

I have been using VS2015 professional for about a year now but I had a power failure on my PC and after restarting VS2015 fails to run.
The startup logo appears for about a second and then disappears.
On the command line:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>devenv /setup
Package 'Async Query Service Package' failed to load.
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>
The problem seems to be Async Query Service Package.
In the activitylog.xml file I see error:
<entry>
<record>5</record>
<time>2018/03/01 14:48:06.133</time>
<type>Error</type>
<source>VisualStudio</source>
<description>LegacySitePackage failed for package [Async Query Service Package]Source: &apos;Microsoft.VisualStudio.Shell.14.0&apos; Description: Could not load file or assembly &apos;WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35&apos; or one of its dependencies. The system cannot find the file specified.
System.IO.FileNotFoundException: Could not load file or assembly &apos;WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35&apos; or one of its dependencies. The system cannot find the file specified.
File name: &apos;WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35&apos;
at Microsoft.VisualStudio.Shell.ThreadHelper.SetUIThread()
at Microsoft.VisualStudio.Shell.ServiceProvider.CreateFromSetSite(IServiceProvider sp)
at Microsoft.VisualStudio.Shell.Package.Microsoft.VisualStudio.Shell.Interop.IVsPackage.SetSite(IServiceProvider sp)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
</description>
<guid>{DD7B74B5-C1F9-411A-B22E-5E711592BC6B}</guid>
<hr>80070002</hr>
</entry>
Do I need the Async Query Service Package? how can I disable it I don't believe I need it.
I only need the C++ language.
I followed pretty much all the advice in this post:
Packages not loading after installing visual studio 2015 RTM
But the basic uninstall and re-install doesn't fix the issue.
What can I do to fix this issue?

How to run Code Analysis on x64 Project in Visual C++?

I am trying to run the code analysis of Visual Studio 2015 on my x64 VC++ project. However I get the following error:
Error C1250 Unable to load plug-in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\localespc.dll'
I am activating the x64 toolset of Visual Studio by running the batch script "vcvarsall.bat amd64" before I start the IDE. Visual Studio is run with the "/useenv" option afterwards.
When I check the VC++ environment variables, I can see that the following path is contained in the PATH variable:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64
How can I tell Visual Studio to use the code analyzer (localespc.dll) from there and not the x86 version which it apparently tries to use (according to the error message).
Thanks a lot for your help!
I was having the same issue with my 64-bit C++ projects. I discovered simply renaming/removing localespc.dll from VC\bin allowed the Code Analysis builds to succeed and still report analysis warnings. It seems if VS doesn't find this dll in the VC\bin directory then it won't add the compiler switch for /analyze:plugin but otherwise passes all the other switches required by the Code Analysis.
Set the following property in your project file: <PreferredToolArchitecture>x64</PreferredToolArchitecture>
This tells Visual Studio to use the 64-bit version of various tools, including code analysis. I found How to make Visual Studio use the native amd64 toolchain helpful on the topic.
Note that renaming localespc.dll no longer solves the problem with Visual Studio 2017. It seems that setting PreferredToolArchitecture is Microsoft's intended way to do this.

How to make Visual Studio use the native amd64 toolchain

How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.