Trying to get a build for a visual studio 2010 data tools project working on our build server. The server is 2008 R2 (64bit) and I have followed the instructions here for installing the necessary prerequisites. The project builds fine locally on a full VS 2010 install (doesn't it always!) but on the build server I'm seeing the following error (edited for brevity and anonymity):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(513,5): error MSB4018:
The "SqlBuildTask" task failed unexpectedly.
System.MissingMethodException: Method not found: 'System.Collections.Generic.Dictionary`2<System.String,System.String> Microsoft.Data.Tools.Schema.Sql.Build.SqlPropertiesHelper.ParseContributorArgs(System.String)'.
at Microsoft.Data.Tools.Schema.Tasks.Sql.SqlBuildTask.ExecuteValidateModelStep()
at Microsoft.Data.Tools.Schema.Tasks.Sql.SqlBuildTask.ExecuteStep(Func`1 step)
at Microsoft.Data.Tools.Schema.Tasks.Sql.SqlBuildTask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
Any ideas on how to resolve this issue?
Apologies for self answering but hopefully this helps someone.
I looked in the SqlTasks.targets file and saw the SqlBuildTask originated from the "C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.Data.Tools.Schema.Tasks.Sql.10.dll" file. As the build was working locally I compared the versions between there and the build server. I noticed some DLLs had the same version but others were different. I tried to reflect in to find where the "missing method" was supposed to reside but gave up and decided to copy the contents of the folder from my dev machine over the same folder on the build server excluding the "en" and "1033" folders.
This seems to have resolved the issue, I can only assume that somewhere in the ridiculous number of separate installs I've had to do on the build server, dlls that are out of step with each other have been introduced and this has caused the problem.
Would be great if someone could properly explain or suggest a more legitimate solution.
There is also an issue with SSDT in Visual Studio if you install SQL Server 2012. Cure for me was to reinstall the latest SSDT after the SQL install. I note the question refers to VS2010 but the SSDT issues seem to be everywhere.
There is some more info here: http://fubnuts.wordpress.com/2013/05/31/fun-with-vs2012-sql-server-projects-and-sql-server-2012/
SSDT download here: http://msdn.microsoft.com/en-US/data/hh297027
Related
What to do to solve "The “GetDeploymentPathFromVsixManifest” task failed unexpectedly" when trying to debug a VS extension project??
Same question was already asked multiple times with different source reasons, all for VS2017 usually for upgrading VS extensions from VS2015, and it should have been solved with VS 2019. Yet, it just popped up.
The "GetDeploymentPathFromVsixManifest" task failed unexpectedly.
System.TypeLoadException: Method 'get_JoinableTaskFactory' in type 'Microsoft.VisualStudio.Sdk.BuildTasks.ExtensionEngineHost' from assembly 'Microsoft.VisualStudio.Sdk.BuildTasks.16.0, Version=16.9.2017.12405, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' does not have an implementation.
at Microsoft.VisualStudio.Sdk.BuildTasks.ExtensionManagerUtilities.GetExtensionEngine(ISettingsManager manager, Boolean deletePendingUninstalls)
at Microsoft.VisualStudio.Sdk.BuildTasks.GetDeploymentPathFromVsixManifest.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
I have tried all the solution for the same error found on SO, so far to no avail. I am using VS 2019 Community 16.9.2, updated all packages, downgraded some to try, nothing really changes this error.
This is my first attempt on VSIX and I just downloaded an existing project from github and compiled it.
The github project is working (probably) since the extension is available on the marketplace.
Any other suggestions? Searches on this error in combination with the JoinableTaskFactory dont return exactly many results.
For me the solution was to do at least one of the following steps:
Delete the obj-folder in the project
Execute Reset the Visual Studio 2019 Experimental Instance. You can find this tool when you search it in the windows search bar.
Clean and Rebuild the project
Sometimes it helped if I did only one step and sometimes it only worked after doing all the steps.
I couldn't find out if there is a specific pattern behind, but doing all of the above steps always fixed the error for me.
Another issue where I got the same error was if there was the wrong external program selected under Project Properties -> Debug -> Start external Program. For VS2019 I need to select C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.exe
If I switched between Visual Studio Versions, then sometimes a different Visual Studio version was selected.
Uncheck: "Deploy VSIX content to experimental instance for debugging"
in solution properties->VSIX
Also Update installed NuGet packages.
I am having an issue rebuilding a multi-project solution that contains an installer project. I keep getting the error: ERROR: Unrecoverable build error
I have scoured Google and this site and have tried the following, with no success;
Repairing VS
Repairing SSDT
Uninstalling SSDT
Registering both mergemod.dll and ole32.dll after closing VS and then rebuilding
If anyone has not been able to solve this issue using the above methods, I'd love to hear about it!
Thanks!
I had a similar issue yesterday (but with VS 2008). I did the following 3 steps and it fixed the issue:
Register the DLL mergemod.dll (regsvr32.exe C:\Program Files (x86)\Common Files\Microsoft Shared\MSI Tools\mergemod.dll)
Register the DLL ole32.dll (regsvr32.exe ole32.dll)
Delete the cache/temporary visual studio files – which get generated as part of the builds. (C:\users{BUILD_USER}\appdata\local\temp).
Hope that helps!
I have encountered a bizarre situation in which.....
a Win32 project (originally compiled/run using Visual Studio 2010) has been successfully carried over/updated and successfully compiled under Visual Studio 2015 on the same computer (mentioned just in case that is somehow relevant).
I now need to continue development of the project on a different computer. So I copy the ENTIRE contents of the project folder to an identically named folder on the new computer, with VS 2015 installed. The only difference being that the project folder is now on the D: drive rather than C: as in the original computer.
When I try to compile the program I get:-
fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
I experienced this error in the past with Visual Studio 2010 and fixed the problem as advised in previous articles such as:
Failure during conversion to COFF: file invalid or corrupt
In this case however the puzzle is that, as mentioned above, the project has already successfully compiled on the computer it was copied from AND the new computer appears to have a correct and up to date VS2015 installation (e.g. the issue cannot be due to incorrect version of the CVTRES.EXE file - as was case when the same error was encountered in the past with Visual Studio 2010)
As far as I can tell the configuration settings for both VS2015 installations, on both computers are the same. The only difference as far as I can tell being that on the new computer the project now resides in a different drive/path - although the project folder is indentically named.
Can this really be the source of the problem?
The problem has now been, apparently, solved. I tried the /verbose option but that did not reveal any information or insight of any use.
The computer on which the project had been transferred to had Visual Studio 2010 WITHOUT service pack 1 installed. As an entirely separate exercise I proceeded to install service pack 1 (from a previously saved/archived ISO file). It failed to install. I then uninstalled VS 2010 from the computer.
I then tried again to compile my project using VS2015 - and again it failed, giving the error 1123.
I then performed a FULL re-installation of VS2010. I followed this with an another attempt to install the service pack 1 - which then succeeded.
After all this I then attempted to compile my project in VS2015 - and it succeeded! The connection with the VS2010 may be completely coincidental? But I mention this here for the record in case anyone else encounters a similar circumstance.
The puzzle is how, if at all, can the state of the VS2010 installation influence the ability to compile the project in VS2015. The concern, more importantly, is that my continued ability to work on/compile the project using VS2015 will be dependent on the computer keeping VS2010 w/SP1 installed?!
I have found various iterations of this question across a number of websites, however so far I have not found anything that provides a full answer that worked.
I have just set up a number of Visual Studio Test Agents that all appear to be behaving and running most of the unit tests we are planning on initially running on them. However when I came to checking one of the unit tests it is failing on the line:
using (ShimsContext.Create()),
With the stack trace:
Result Message:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables.
Having read some other posts I installed Visual Studio 2013 on the test agent and confirmed it would run the test locally. I then set COR_PROFILER_PATH to the profiler that was being used on my machine which was installed at: “C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\IntelliTrace\12.0.0\Microsoft.IntelliTrace.Profiler.12.0.0.dll”.
It then failed in the same place with the trace:
Test method threw exception:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to get profiler module handle 'C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\IntelliTrace\12.0.0\Microsoft.IntelliTrace.Profiler.12.0.0.dll'. The specified module could not be found ---> System.ComponentModel.Win32Exception: The specified module could not be found
The suggestion is the profiler has been loaded under a separate process and can't be used. Has anyone had any success with this or similar set ups? At a fundamental level can Visual Studio Test Agents run tests with Fakes?
Thanks
I know this is a bit old, so the OP probably got his answer, but for anyone else, I opened a ticket with Microsoft on this issue, and the answer we came to after an hour and a half of looking at my setup for this problem:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables.
, was that I was using mstest.exe and I should have been using vstest.console.exe. In my case it was because I have Fakes test in my code now.
I'm using Visual Studio 2013 update 4.
I was having the same issue with a project I was working on. I found this issue noted:
https://connect.microsoft.com/VisualStudio/feedback/details/832744/unable-to-debug-shims-based-tests-unittestisolation-exception
There was an attached project, so I downloaded the project and ran the only unit test. Same error - the unit test was not successful. However, I right-clicked on System under the References, and clicked Add Fakes Assembly. Once it had generated the fakes for System and mscorlib, voila! The test turned green.
I was able to reproduce the issue in my project - I did not have fakes being generated for System. Once I generated them for System, my tests went from red to green!
Side note -- If you don't want to generate ALL of the fakes for System and mscorlib, you can modify the .fakes files like so.
mscorlib.fakes:
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
<Assembly Name="mscorlib" Version="4.0.0.0"/>
<StubGeneration Disable="true" />
<ShimGeneration Disable="true" />
</Fakes>
System.fakes:
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
<Assembly Name="System" Version="4.0.0.0"/>
<StubGeneration Disable="true" />
</Fakes>
I could not disable ShimGeneration for System.fakes - the test would fail.
I hope this fixes the problem for someone else - the error is extremely vague!
(I'm assuming your Test Agent is also a Build Agent.)
Is the build service version synced with the Visual Studio version which is installed?
I had the same issue in the following environment:
TFS 2013
Build Server w/ TFS 2013
Visual Studio 2015.3 installed in the build server
When I updated the TFS version on the build server to 2015.3, the issue stopped happening.
I know it may not make sense, but solved the problem as the TFS 2015 XAML Build is compatible with TFS 2013.4 app tier.
I recently create a couple of VSPackages for some Visual Studio extensions (menu bar/command). I compiled them correctly yesterday, checked into TFS (i'm the only one touching this project, FYI). I had already installed these extensions and were working fine. Today it doesn't compile! I get the following error:
Exception has been thrown by the target of an invocation.
This doesn't tell me anything, so i fired up Visual Studio with the following command:
devenv.exe /Rebuild > out.log
In my out.log, I see the following:
C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets(420,5): error : Exception has been thrown by the target of an invocation.
I have been stuck on this for hours and can no longer build these VSPackages. Anyone? This is really frustrating. I have already tried cleaning project/rebuilding/build using Visual Studio itself (not command line)
I've experienced this issue several times in both vs2010 and vs2012, and manually deleting the "bin" and "obj" folders from the project then doing a "rebuild" normally does the trick.
Further to the answer provided by the OP, I will provide it here for completeness instead of relying on the external link remaining live:
Quoted directly from the MSDN forum answer:
Do you happen to have these extensions installed to the AllUsers
location (i.e. %VSInstallDir%\Common7\IDE\Extensions)?
You mentioned in your initial post that "I had already installed these
extensions and were working fine."
The task that's failing (based on the line number in the targets file)
is the UninstallExtension task. The only reason I'm thinking this task
would execute and fail in your situation is if you're building an
extension that's already installed to the Common7\IDE\Extensions
directory.
Regards, Aaron
I find myself on this question because of exactly the same build issue of a VSIX Installer Project for our project templates. This solved my issue.
Indeed, I uninstalled the prior version of our templates and the build occurs without issue.
Have you double checked that all of your projects are using compatible framework versions?
As in you can't use a .Net 4.0 assembly in a .Net 3.5 project.
Is the project linked with source control like TFS? If so then take latest from TFS and try again.
Are you running Visual Studio as Administrator?
Maybe you have insufficient rights for some file (copy/move/delete) especially in bin or obj folders.