I have a problem in Team Explorer (VS2017) where I branch my code from the master and call it test (for example).
When I made changes in test branch and switched back to master, the changes in the test branch is also showing in master.
I don't understand why this is happening, I only noticing this after I upgraded from VS2015.
I have uninstalled VS2015 and I cannot go back and verify that this is a problem with VS2017.
Is there a settings that I have overlooked in VS2017?
Team Explorer will not automatically merge the test branch back into master (in VS2017 or VS2015), so let's look at your workflow that leads to this result. Could you please list for me each step you take when starting at the master branch, creating the test branch, committing changes, etc. If possible, screenshots at each step may help me look for other clues.
Thanks!
Related
On a project I am working on, I am maintaining some Feature Tests written in SpecFlow. Our team started using Visual Studio 2017 about a year ago, and we finally got around to doing some upkeep on our tests!
Our tests for the project I'm working on were originally written in SpecFlow 2.3.2, and were last updated in Visual Studio 2015.
The SpecFlowSingleFileGenerator is known to not work on VS 2017, so I spent the better part of yesterday changing our suite to use the MSBuildSingleFileGenerator instead as detailed in this article in SpecFlow's official documentation
Problem:
Locally, I can build my solution, including the Feature Test project just fine.
However, I keep getting the following error when I try to build the project on our build server:
[exec] C:\CheckoutDirectory\My Awesome Project\packages\SpecFlow.Tools.MsBuild.Generation.2.3.2\build\SpecFlow.Tools.MsBuild.Generation.targets(45,5):
error MSB4036: The "GenerateAll" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin" directory. [C:\CheckoutDirectory\My Awesome Project\AwesomeProject.FeatureTest\AwesomeProject.FeatureTest.csproj]
I should point out that our team has no experience with writing MS Build tasks, as hitherto we haven't needed to; we use NAnt build scripts on TeamCity to manage our build work. It's clear that error message would be helpful...if we knew literally anything about it.
Now, normally the correct answer would be: Google it. I did that, and this specific error has no pertinent results.
Additionally, this is blocking my team, since we need our build to work. I don't have the time to do the research and education necessary to properly understand how MS Build technology works. That wil have to come later.
Question:
Bearing in mind that SpecFlow has broken our process, and our team's lack of knowledge about the MS Build system: I need to know how to get around the "GenerateAll" task was not found error. What do I do to get around it?
Secondary Question:
I'm also open to lateral thinking. Is there some way to hack either VS 2017 or SpecFlow to make the SpecFlowSingleFileGenerator "compatible" with each other? The objective here is NOT to avoid making changes, but to control the changes. I need a path towards transitioning from the old file generator to the MS build generation system.
Additional Information:
So, I did some digging, and I found a place where "GenerateAll" is being called in the SpecFlow.Tools.MsBuild.Generation.targets file:
<Target Name="UpdateFeatureFilesInProject"
DependsOnTargets="BeforeUpdateFeatureFilesInProject"
Inputs="#(SpecFlowFeatureFiles)" Outputs="#(SpecFlowFeatureFiles->'%(RelativeDir)\%(Filename).feature.cs')">
<GenerateAll
ShowTrace="$(ShowTrace)"
BuildServerMode="$(BuildServerMode)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
ProjectPath="$(MSBuildProjectFullPath)"
ForceGeneration="$(ForceGeneration)"
VerboseOutput="$(VerboseOutput)"
DebugTask="$(SpecFlow_DebugMSBuildTask)"
>
<Output TaskParameter="GeneratedFiles" ItemName="SpecFlowGeneratedFiles" />
</GenerateAll>
</Target>
Because I've confirmed that this is being copied out to the build server, the situation is yet more mysterious. It appears that the NuGet package is being pulled down faithfully. Therefore, I can't figure out why my local copy is behaving differently than the copy on the build server.
I am not sure where you found this statement:
The SpecFlowSingleFileGenerator is known to not work on VS 2017
The SpecFlowSingleFileGenerator is working in VS2015, VS2017 and VS2019. We see it as a legacy feature, but it's still there. Since some weeks it is disabled by default, but you can enable it in the options.
It works for SpecFlow >= 2.3.2 and 2.4. For SpecFlow 3 you have to use the MSBuild integration. There are some problems with older versions of SpecFlow, but with them it can also work. It depends on your setup.
About your MSBuild error:
The MSBuild Task for SpecFlow < 3.0 is in the specflow.exe. Is it on your build server?
It is part of the SpecFlow NuGet packages. Normally you get this kind of error if MSBuild can't find the assembly where the task is.
For "debugging" problems with MSBuild, I can highly recommend to use the MSBuild Structured Log Viewer (http://msbuildlog.com/). With it, it makes it easy so see what is happening in your build.
We have an example for MSBuild Code- Behind- Generation with SpecFlow 2.3.2 here: https://github.com/techtalk/SpecFlow-Examples/tree/master/MSBuild/OldCSProj_SpecFlow232
You could compare your project with this example.
Full disclosure: I am one of the maintainers of SpecFlow.
The code coverage tool in VS2017 enterprise no longer shows what application code is covered. Whether I run it on selected tests or all tests, it shows what code in the unit tests are covered, but shows the code actually being tested at 0%. When I first started using the tool it worked just fine and showed application code coverage. I only check coverage occasionally, so I'm not sure when it broke or what I might have done to cause the issue. I'm thinking that there is something in the Registry that is causing it since I haven't been able to find anything in Tools/Options/...
I installed JetBrains dotCoverage and it does the same thing even when I exclude the unit test project from the coverage session. I've tried to repair the VS installation. My next step is uninstall/reinstall. However, unless that cleans up the registry where I think the configuration error is, it will fail to address the problem.
So any suggestions on where I can look to figure this out would be appreciated.
Using CUITe testing framework in VS2012, I created a coded UI test. This test works as expected when right clicking the test, and hitting "run test" in VS2012.
We are in the process of migrating to VS2015, so I'm trying to go through our solutions to make sure they are behaving as expected. In this solutions case, we are running into an issue where when attempting to run a test, the output pane states:
There is no test with the specified Id (guid listed)
And no CUITe tests are run.
I have confirmed that normal coded UI tests are running in VS2015, it is specifically coded UI tests created using CUITe that are failing to run.
Don't know if anyone will have any workarounds for this, but I figured I'd give it a shot. I have additionally added all of the "Microsoft Testing" dlls to the solution in a separate folder, in order to ensure the solution is using the "specific versions" of the testing DLLs. This did not solve the problem.
The issue was due to CUITe not having been compiled/provided a build definition for VS2015.
In the current GitHub repo of CUITe (code plex URL from the original question no longer the "active link") provides a new build that addresses the issue.
Current URL for CUITe is:
https://github.com/icnocop/cuite
Issue was resolved here.
Since I installed VS2015, I can't run unit tests on neither VS2013 nor VS2015
Below is the error:
Model compatibility cannot be checked because the database does not contain model metadata. Ensure that IncludeMetadataConvention has been added to the DbModelBuilder conventions.
Anybody experiencing the same problem?
I had the same problem (also after installing VS2015). What solved it for me was to move the solution. Others reported that "creating a new solution and adding all the projects again solved it". I think the test runner somehow marked the solution (via the path). So just changing the path works.
I think (but I did not try) that after a single successful run (move solution, open solution from new directory, running tests, closing solution, move back) everything could work again as the database should be setup correctly.
I have couple of developers changes and they are all checked in to source control. Team city build is failing because of one of the developers changes. Since I already ran the build with both developers changes, how do I revert back to what it was originally (before two changes state)..what I want to do basically is, since it was a successful build until yesterday, I want to go back to that build, so that at least the website is functioning properly and then just run the build with only one developer changes and not the ones that messed up the build.. thanks for the help. Can I do this with teamcity..
You can run a "history" build in TeamCity, selecting a change in the Custom run build dialog (click on ellipsis of the "Run..." button). If you want then use the artifacts in other builds, you can use "Promote" action from the finished build's "Build Actions".
Or you can use a usual approach to revert the changes in the version control and trigger a new build in TeamCity manually.