Usually every new major version of Team Foundation Server comes with a new version of a default XAML build process template.
I'm well aware of the new build vNext system introduced in TFS 2015, but regarding the legacy one - is there a new build process template for it?
No, TFS2015 uses the same version of build process template as TFS2013. The Default Template is TfvcTemplate.12.xaml
Related
This describes a scenario that I find myself in now and then when I realize I should have worked in a development branch in TFS. Then I would like to shelve my changes and unshelv into a dev branch, alternatively create a branch from "Main" with saved, uncommitted changes.
What is described on this linked page and many other pages is possible with earlier versions of VS and TFS using the TF power tools command utility:
http://geekswithblogs.net/TarunArora/archive/2011/06/06/unshelve-shelveset-created-from-one-branch-to-another.aspx
Now those features are no longer available, because "most of the previous Power Tools have been integrated into TFS 2017" (according to https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2017-relnotes ). But there is no command line utility AFAIK available to enable such operations.
How can I achieve unshelving to another branch with Visual Studio 2017 and TFS 2017?
Alternatively, how can I create a branch from "Main" with saved, uncommitted changes?
With older versions of Visual Studio (2015 and older), the Power Tools extension (https://marketplace.visualstudio.com/items?itemName=TFSPowerToolsTeam.MicrosoftVisualStudioTeamFoundationServer2015Power) used to unshelve to a different branch. But unfortunately this tool does not exist for VS2017.
I have tried another extension MutliMerge - https://marketplace.visualstudio.com/items?itemName=Jesusfan.MultiMerge2017&ssr=false#overview
I was able to unshelve from a branch to a different branch.
I have ensured that there were no pending changes and both branches were up to date.
Note: the tool did not automatically show me the target branch but I was able to edit it and get to work.
How do I get the UWP back into Xamarin.Forms Cross-Platform creation to have the templates ready to roll?
After picking through the release notes, playing with VS2019's UI and a few hours of web searching, I have only found others posting about the problem in the preview versions. Some say UWP is gone forever, some say it just isn't included by default (so Microsoft can brag about how the install went from 23GB to 8GB or something like that) - but no help on HOW TO re-enable it, or add it to the project creation wizard (apart from adding a blank UWP project sans all code that is in the iOS/Android projects).
<Project Sdk="Microsoft.NET.Sdk">
// the code is not the problem here,
// getting TO the code is the problem
</Project>
EXPECTED:
In VS2017, Xamarin.Forms Cross-Platform supplied iOS + Android + UWP templates by default.
ACTUAL:
Visual Studio 2019 seems to have removed the UWP template from Xamarin.Forms Cross-Platform project creation.
Update 9 apr.: a new version of 2019 was released which reinstates the UWP templates again
It is correct that the UWP template is removed from VS2019, I don't know the reason behind it, but we'll have to deal with it. There is however a page that runs you through the process step by step. It has been there for a while for the projects that were created in Visual Studio for Mac, which don't include the UWP template as well. The full description can be found here: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/platform/windows/installation/ taken from this page:
First, right-click on the solution and select Add > New Project... and add a Blank App (Universal Windows) project:
Then, select the minimum and targeted UWP versions.
Right-click on the UWP project and select Manage NuGet Packages... and add the Xamarin.Forms package. Ensure the other projects in the solution are also updated to the same version of the Xamarin.Forms package.
Also, make sure the new UWP project will be built in the Build > Configuration Manager window (this probably won't have happened by default). Tick the Build and Deploy boxes for the Universal project:
Right-click on the UWP project and select Add > Reference and create a reference to the Xamarin.Forms application project (.NET Standard or Shared Project).
In the UWP project, edit App.xaml.cs to include the Init method call inside the OnLaunched method around line 52:
// under this line
rootFrame.NavigationFailed += OnNavigationFailed;
// add this line
Xamarin.Forms.Forms.Init (e); // requires the `e` parameter
In the UWP project, edit MainPage.xaml by removing the Grid contained within the Page element. Then in MainPage.xaml, add a new xmlns entry for Xamarin.Forms.Platform.UWP, like this: xmlns:forms="using:Xamarin.Forms.Platform.UWP".
In MainPage.xaml, change the root <Page element to <forms:WindowsPage, like this:
<forms:WindowsPage
...
xmlns:forms="using:Xamarin.Forms.Platform.UWP"
...
</forms:WindowsPage>
In the UWP project, edit MainPage.xaml.cs to remove the: Page inheritance specifier for the class name (since it will now inherit from WindowsPage due to the change made in the previous step)
public sealed partial class MainPage // REMOVE ": Page"
In MainPage.xaml.cs, add the LoadApplication call in the MainPage constructor to start the Xamarin.Forms app:
// below this existing line
this.InitializeComponent();
// add this line
LoadApplication(new YOUR_NAMESPACE.App());
Add any local resources (eg. image files) from the existing platform projects that are required.
And now it should work as before. I know, it's a hassle to go through it for something that just worked before. Sorry about that, but this should get you there as well.
With the Update 16.0.1, Microsoft restored the UWP creation on new Xamarin.Forms applications
except when you try to use Shell, which is not available for UWP:
Issues fixed in Visual Studio 2019 version 16.0.1
Add option for Windows (UWP) platform when creating new Xamarin.Forms project from 'Mobile App (Xamarin.Forms)' project
template.
EDIT (7/17/2021): i have started a new xamarin forms solution and it seems all 3 platforms are available again in VS2019 on all prebuilt templates (blank, master-detail, tabbed layout).
thank you, everyone, for your input.
great information!
it helped me steel myself to face the fact:
UWP is gone (for now) from Xamarin.Forms new project scaffolding.
but, the (simplest) solution to the question asked that i have found is:
open VS2017. create new Xamarin.Forms cross-platform project.
once it is open, save-all.
then close VS2017 and open in VS2019 if so desired.
Summary:
The TFS 2017 Build I inherited is not compiling a new exe.
Any ideas on what to to review?
More Detail
A coworker set up a TFS Build and then totally jumped ship (Gave his 2weeks but then stopped coming into work.)
Anyway, he set up a TFS 2017 Build and it runs successfully (no errors) but when I look at the deployment directory (We are using Octopus Deploy.) it has an older version of the exe (dated 10/11). It looks as though something is working since the .config file is being updated by Octopus.
I am very new to setting up a TFS Build so any ideas would be helpful.
Thank You,
I was able to resolve this issue.
The Version Numbers were not set up correctly. Octopus Deploy was pulling an old version of the Package from 10/11 because that Version looked like the latest. However, it was not.
To resolve we deleted the old Packages in Octopus Deploy.
I'm building a R# plugin and decided to cover it with tests. However, I noticed, that plugin tests cannot be run using the R# runner if plugin target version is the same as R# version.
For instance, if you try to run tests using JetBrains.ReSharper.SDK.Tests of version 2016.2.20160818.171542, you'll get the following error:
ERROR System.TypeLoadException:
Method 'RunTests' in type 'JetBrains.ReSharper.UnitTestRunner.nUnit26.BuiltInNUnitRunner' from assembly 'JetBrains.ReSharper.UnitTestRunner.nUnit26, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
In previous versions the error was different.
Likely, that happens because R# runner and SDK assemblies make a mix.
Is there any way to configure project/R# to be able to run plugin unit tests using the R# runner? Likely, R# dev team uses their own runner.
Thanks!
Unfortunately, this is a bug in the ReSharper runner in 201.6.2. Something to do with having multiple copies of the same assemblies in the same process - the assemblies from the install, and the assemblies from the bin folder. Something's getting messed up along the way.
You can subscribe to, vote and track this issue: RSRP-460399
The workaround is to install an older version of ReSharper into a Visual Studio "experimental instance" aka "custom hive", and use this instance to develop and test the plugin. The normal instance can be used for other day-to-day development.
You can download an older version of ReSharper here (e.g. 2016.1.2), and in the installer, click Options and enter the name of a custom instance, e.g. "Plugins". Then create a new shortcut to Visual Studio and set the command line to "devenv.exe /rootSuffix Plugins" (or whatever you called the custom hive).
R# and SDK must be either of different major versions, or of binary compatible versions. Unfortunately, within EAP the internal APIs inside the test runner have changed, so R# and SDK from different EAPs are not compatible.
I'v been struggling with correctly configuring Visual Studio (2013 and 2015) to be able to create a new Build Platform based on the x64 preset which in addition adds a preprocessor definition (c++) macro to the build commandline.
What I want is to be able to select a new Platform from the dropdown menu, but a new one which is not Win32 or ARM. In my C++ code I use a macro (_SSE4) to compile math functions optimized for SSE4.
The first problem I have is that I cant create a new Platform in the Configuration manager named x64_SSE4:
Error message: New project platforms cannot be created because this new solution platform is not supported by any of the projects.
I don't want to create a new solution configuration with DebugSSE4 and ReleaseSS4 because I dont want to have 4+ different configurations (including the normal Debug & Release configurations). This new platform should be valid for each project in the solution.
If creating a new Platform with a new name would work, i could create a new PropertySheet which checks for $(Platform) == "x64_SSE4" and then set the preprocessor definiton by hand.
Is there a more elegant way to introduce a new platform with preprocessor definitions?
Thanks for your help!