We have TeamCity with 2 build agents:
VM with Windows 8.1
VM with Windows 10
Some of our projects use MS Build 12, others use MS Build 14. Some use MS Test 12, others use MS Test 14.
I installed the build tools for Visual Studio 2013 and Visual Studio 2015 on both machines. All builds were succesful, but our tests weren't.
Some of the projects configured with MSTest 2013 had failing tests on the Windows 10 VM and some of the projects configured with MSTest 2015 had failing tests on the Windows 8.1 VM.
The exception I get is the same for all the tests. This is the one I get on the Windows 8.1 VM:
System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.
This is the exception I get on the Windows 10 VM:
System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.
Everything worked fine on all of our development machines (some devs use VS 13, other devs use VS 15).
The problem was fixed on the Windows 10 VM by installing Entity Framework 6 Tools for Visual Studio 2013.
As of now the Windows 8.1 VM has the tools for VS 2013 and the Windows 10 VM has the tools for VS 2013 and VS 2015.
As of Visual Studio 2015, the tools are included in the installation of Visual Studio itself. I'm not going to install VS on a build agent (the Windows 10 build agent is also a development machine, that is why it already has the tools installed)...
How can I get this to work on my Windows 8.1 VM, with or without installing the EF tools? Shouldn't installing the build tools be enough for a build agent?
Related
We have recently upgraded some projects to .net framework 4.7.1 but our on premise build agent is failed to run the build solution build step. We are using Visual Studio Team Services.
The full error is...
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets (1122, 5)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1122,5): Error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.7" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
The build machine is a windows server 2016 azure VM with Visual Studio 2017, 15.4.4 installed. I manually installed the 4.7.1 .net framework sdk from here: https://learn.microsoft.com/en-us/dotnet/framework/whats-new/index#v471.
I've rebooted and restarted the agent service but still it failed with the above.
Any ideas how to resolve this issue?
The full build solution log file can be found here: Build solution log gist
Thanks,
It turned out the issue was due to not having the 4.7 SDK and 4.7 targeting pack checked under individual components in Visual Studio.
The goal
I would like to use a Windows Server 2016 (x64) for remote debugging of UWP applications. The reason? My working PC still runs a Windows 7 instance and it is not possible to deploy an UWP app on a Windows 7 machine.
The problem
I have already installed the Remote Tools For Visual Studio 2015 on the Windows Server 2016 machine and started it on port 4020. Authentication mode was set to "None". I have enabled Developer mode on the server as well. Also I have set up my project in Visual Studio to use the remote machine for debugging.
The problem is, whenever I try to deploy (just deploy, not even debug) my solution to the server, the following happens:
Visual Studio shows the following output:
Deploy started: Project: MyProject.UI.Uwp, Configuration: Debug x86
Starting remote deployment...
Reading package recipe file "C:\SourceCode\MyProject\MyProject.UI.Uwp\bin\x86\Debug\MyProject.UI.Uwp.build.appxrecipe"...
and then hangs forever.
In the meantime, remote tools on the server show the following output:
UserAbc connected.
This indicates there must be at least some communication between my Windows 7 PC and the target Windows Server 2016 machine.
No error message is displayed whatsoever (neither in Visual Studio, nor in the Remote Debugger).
The question
Any idea why the deployment hangs forever without an error message? Or am I trying to achieve an impossible task? Is the Windows Server 2016 capable of running UWP apps at all?
Update
I installed VS 2015 Update 3 directly on the Windows Server 2016. I was able to create and debug a simple UWP app directly on the server so the server is clearly able to run an UWP app. However I am still unable to make the remote debugging working. Maybe the problem is completely on my local Windows 7 PC and has nothing to do with the Windows Server. It is strange that the process hangs while "Reading package recipe file". Could it be that an antivirus is intercepting?
Thanks for your feedback. There is a similar issue when I try to deploy the UWP project to a remote machine on Windows 7. We have communicated about this using our internal channel. Unfortunately, Visual Studio 2015 or Visual Studio 2017 doing UWP development on Windows 7 is not a recommend scenario.
For Visual Studio 2017, using Tools for UWP App Development is not applicable on Windows 7. See Visual Studio 2017 Support for Windows Development.
For Visual Studio 2015, the official support for Windows Universal is "Build only". We can use Visual Studio 2015 to build UWP apps on Windows 7, but some other Visual Studio features for Windows Universal development may be degraded. See Visual Studio 2015 Support for Windows Universal, Windows Store, and Windows Phone App Development.
To develop Windows Universal Apps, Windows 10 is strongly recommended. With Windows 10, you can get the best experience of UWP development.
Our product needs to be compatible with versions of windows including Server 2003 and XP.
We have code first entity framework projects with various migrations.
We are deploying these migrations to create or update a database using the "migrate.exe", file version 6.0.21211.0, supplied in entity framework 6.0.2 nuget package.
When using XP itself with visual studio 2010 or Windows 7 with visual studio 2013 to install the package every time we run "migrate.exe", on an xp or server 2003 machine, we are getting a "not a valid win32 application" exception.
Is there a good reason why "migrate.exe" will not run on windows xp and windows server 2003 other than the fact they are operating systems that nobody really wants to support any more?
I managed to resolve this issue by downloading the source code for 6.0.2 version of entity framework, un-signing it in properties, then building it through .net 4.0 and not 4.5 by changing the solution configurations to Release40.
Source code can be found here:
http://entityframework.codeplex.com/SourceControl/changeset/7648d33dfb53589d9c32b605c61758a5a6c0b80b
I found it quite difficult to locate it.
You probably don't have .NET Framework installed on the machines where it fails.
(As a side note I believe both XP and 2003 go out of support soon so you may want to upgrade your environment...)
I am receiving the following error when attempting to publish a Visual Studio LightSwitch 2011 project ...
Error 1 The "VSMSDeploy" task failed unexpectedly.
System.ArgumentException: Version string portion was too short or too long.
at System.Version.VersionResult
.SetFailure(ParseFailureKind failure, String argument)
at System.Version.TryParseVersion(String version, VersionResult& result)
at System.Version.Parse(String input)
at System.Version..ctor(String version)
at Microsoft.Web.Publishing.Tasks.Common.Utility.CheckMSDeploymentVersion()
at Microsoft.Web.Publishing.Tasks.Common.Utility.get_IsMSDeployInstalled()
at Microsoft.Web.Publishing.Tasks.Common.Utility
.CheckMSDeploymentVersion(Task task)
at Microsoft.Web.Publishing.Tasks.VSMSDeploy.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)
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\LightSwitch\v1.0\
Microsoft.LightSwitch.targets 96410Application3
I have tried re-installing Web Deploy (both 2.0, via the website, and 2.1, via the WebPI) but no joy.
It turns out Visual Studio LightSwitch 2011 requires Web Deploy 1.1 which was not installed by its installer (2.0 had previously been installed by WebMatrix and I also tried 2.1 via the WebPI). My problem was solved after I downloaded it from the Microsoft Download Center:
Web Deployment Tool (x64)
Web Deployment Tool (x86)
This did make me wonder why LightSwitch doesn't support WebDeploy 2.0/2.1, and also installs SQL Server Express 2008 rather than 2008 R2, but that is a question for another time
I am trying to run NUnit in Visual Studio 2003 on 64-bit Vista but with no success.
I have set the Debug Mode of the Project to "Program" and the Start Application to "C:\Program Files (x86)\NUnit 2.4.8\bin\nunit.exe". The Test Project is set as the StartUp Project. All the code is in .NET 1.1. Unlike .NET 2.0 the processor architecture cannot be targeted (when a 1.1 executable is loaded on an x64 machine it is run in the WoW64 as a 32-bit process and utilises the 32-bit framework).
After I hit Debug > Start I receive the error window "A project with an Output Type of Class Library cannot be started directly". I am stuck and cannot get NUnit to run.
The nearest related question on stackoverflow dealt with getting NUnit to run on Vista x64 in Visual Studio 2005 "Nunit.exe cannot work on Vista 64bits if x86 build (stackoverflow.com/questions/208985/nunit-exe-cannot-work-on-vista-64bits-if-x86-build).
Additionally NUnit did not install a nunit-x86.exe from the NUnit-2.4.8-net-1.1.msi image.
My Development Environment
Vista x64 with SP1
Visual Studio 2003 (version 7.1.3088)
.NET Framework 1.1 (version 1.1.4322 SP1)
NUint 2.4.8 (installed from NUnit-2.4.8-net-1.1.msi)
I found the issue - and it had nothing to do with Vista x64.
I had set the Debug Mode of the main Project to "Program" and the Start Application to "C:\Program Files (x86)\NUnit 2.4.8\bin\nunit.exe" and not the Test Project.
Even though I had set the Test Project to the StartUp Project the Debug Mode in the Test Project was still set to the default "Project" and not to the "Application". I switched the debugging configurations around; so the main Project was set to "Project" and the Test Project contained the NUnit debugging configurations.
Summary: NUnit does run on Vista x64 in Visual Studio 2003.
IF your app is a 32-bit app, then you have to use nunit-x86.exe, it is built for testing a 32-bit application on a 64-bit system. See detail explanation here: http://www.nunit.org/index.php?p=nunit-gui&r=2.4.2