I have a visual studio solution with non-default configurations and platforms.
I want to build the following combinations:
Configuration Platform
------------ ------
App-Debug | Emulator
App-Release | Emulator
App-Debug | Device
App-Release | Device
As you can see i am not using x86 or ARM or AnyCPU for Platform. I defined my own solution platform.
In Teamcity i define a build step with configuration: App-Debug and Platform: Emulator.
But it ignores the Platform setting and automatically sets x86. So the build fails. How can i make Teamcity compile for a custom Platform property?
Related
We have a Visual Studio solution with several .NET 5.0 projects, one of which is a Windows Application (TargetFramework is net5.0-windows). It obviously fails to build on Linux and Mac. How can we make it so that it would build or not build, depending on the OS? The scenarios we need to support are:
Building from Visual Studio on Windows.
Building from JetBrains Rider on Windows and Mac.
Building from command line on Windows, Mac and Linux. For command line we currently use dotnet build, as well as dotnet test and dotnet pack which build the solution first.
How to run vstest.console.exe targeting the 64-bit platform?
Unit Tests set to target platform x64 were failing to run on DevOps tools (VSTS/TeamCity/Octopus).
[error]Error: None of the provided test containers match the Platform Architecture and .Net Framework settings for the test run.
Platform: X86 .Net Framework: Framework45. Go to
http://go.microsoft.com/fwlink/?LinkID=330428 for more details on
managing these settings.
Locally it is achieved by setting the tests on Visual Studio to run on x64 as default process.
Test tab on VS > Test Settings > Default Process Architecture > x64
When using some DevOps tool, the platform can be specified in the script which runs the vstest.console.exe
In my case, I'm using Azure DevOps Build Definitions, so I set my VS Test task to /platform:x64 through a parameter when running vstest.console.exe.
vstest.console.exe "C:\Project\bin\x64\Release\Project.UnitTests.dll" "C:\Project\bin\x64\Release\Project.UnitTests.dll" /platform:x64 /logger:trx
Once it is set, all x64 targeting Unit Tests dlls will execute successfully.
Check if you have vstest.console.exe under C:\
Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Mi
crosoft\TestWindow\
from cmd go to the path where your projects dll are kept.
i.e. cd C:\Users\krakhil\Desktop\Notes\Practice Codes\VerifyExe\VerifyExe\bin\Debug
Press Enter
Then write -> "C:\
Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Mi
crosoft\TestWindow\vstest.console.exe" VerifyExe.dll
Where VerifyExe.dll is the project dll i want to execute.
I am building Xamarin.Adnroid project with an mdtool from rakefile as a step in TeamCity build configuration.
The call is:
/Applications/Xamarin\ Studio.app/Contents/MacOS/mdtool build "--configuration:Debug" -p:"Project.Droid" -t:Build "Project.sln"
This (and even if I set -p:AndroidSdkDirectory=/Users/user/AndroidSDK) gives an error:
error: The Android SDK could not be found, please set the path to it
in the Xamarin.Android SDKs settings panel.
I can use xbuild to build the project and specify the AndroidSDKPath via:
/usr/local/bin/xbuild Droid/Project.Droid.csproj /p:Configuration=Debug /t:SignAndroidPackage /p:AndroidSdkDirectory=/Users/user/AndroidSDK
but sine my solution hots both, Android and iOS projects, I'd like to be able to build both with mdtool.
Note that this question is unrelated to this one since the later of deals with the UI builds which work great in my case.
I suggest to open Xamarin Studio on the build host and configure the SDK path under Preferences > SDK Locations > Android. That should fix your problem.
I am using
Windows 10 Family x64
Visual studio Community 2015 14.0.25.123.00 update 2
Xamarin 4.0.3.214
Xamarin.Android 6.0.3.5
I am trying to compile and execute with the virtual device Xamarin_Android_API_15
the solution found there :
https://github.com/burf2000/OpenGLXamarin.git
First I had the following error:
"major version 51 is newer than 50, the highest major version supported by this compiler. [javac] It is recommended that the compiler be upgraded."
So I uninstalled JDK 6
Now I have the following error:
Skipped Deploy: Project: OpenGLDemo.Droid, Configuration: Debug Any CPU
Project not selected to build for this solution configuration
In my Solution Configuration Properties, Build is checked for OpenGLDemo.Droid for any CPU
I tried to delete all folders in obj/ and bin/
I tried to Clean the Project
I tried to Unload and Reload the Project.
I still have the same error... HELP
Go to Build->Configuration Manager and check Deploy checkbox for your project.
I fixed it, I don't really know how:
I changed from Active(Debug) to Debug then I unchecked Build for OpenGLDemo.UITests
then from Any CPU to x86, I got a message like "processor mismatch"
then back to Any CPU and I could deploy...
My Windows app has 2 build configurations - x86 & x64.
I have 2 setup projects - one targeting the x86 build to produce a 32-bit MSI, and one targeting the x64 build to produce a 64-bit MSI.
In each setup project, I have added the project output for the specific configuration, e.g. Release | x86 for the x86 Setup Project. This pulls in the detected dependencies (other projects in the solution).
Problem: When I build my project and then look at the source path property of my dependencies, they default to the x86 versions, even if the x64 project output was added as primary output. For example, in my x64 Setup Project, if I build the x86 version in VS, then my x64 setup project dependencies will be pulled from the bin\x86 folder and not the bin\x64 folder.
Ideally I would like the dependencies to remain consistent with the type of Primary Output selected i.e. if my primary output is added from the x86 build, then I want all my dependencies referenced from the bin\x86 folder. If my primary output is added from the x64 build, then I want all my dependencies referenced from the bin\x64 folder.
I am curious to know if there is a way where I can stop the detected dependencies from auto-updating to match the last build configuration in Visual Studio.