I have two projects - "Features" containing specflow features and "Steps" containing Specflow step definitions.
I have the following setting in "Features" project app.config
<specFlow>
<!-- For additional details on SpecFlow configuration options see https://github.com/techtalk/SpecFlow/wiki/Configuration -->
<stepAssemblies>
<stepAssembly assembly="Steps" />
</stepAssemblies></specFlow>
But when i try to debug my feature file I get this error:
Could not load file or assembly 'Steps' or one of its dependencies. The system cannot find the file specified.
what am I missing? Is it not possible to specify features and steps in two separate assmeblies? Thanks.
sorry I got it ! Forgot to add the reference to project "Steps" in the "Features" project
Related
When I open up a build definition I can see the arguments are split into sections with a number prefix e.g. 1. Basic, 2. Misc etc.
However, when I edit the xaml there is no indication as to where these categories are defined.
Can someone provide some guidance as to where they are located within the arguments list?
Here is a similar question except the poster has inquired about a different parameter based off the build settings which I believe is a different case than regular parameters.
Missing ProcessParameterMetadata in TFS DefaultTemplate.xaml: where is for e.g. Items to Build in the Required category
You can open the build template and edit the Metadata argument as shown in the picture below:
Then you can edit the category:
In the XML there is no category as standalone. You can define the category in the Process.Metadata section:
<this:Process.Metadata>
<mtbw:ProcessParameterMetadataCollection>
<mtbw:ProcessParameterMetadata Category="#300 Advanced" Description="Enable MSBuid Multi-proc to build your solutions' projects in parallel, when possible, using all available processors on the build server." DisplayName="MSBuild Multi-Proc" ParameterName="MSBuildMultiProc" />
....
</mtbw:ProcessParameterMetadataCollection>
</this:Process.Metadata>
This is to add new categorys but i dont know where the standard categories are.
Hope that helped you.
Chears
I have a projects in JAVA that I analyze using sonar. Some of the java packages that I have are all under source folder. I also have some test file that I have under a different folders. Now, in Sonar, I organize my projects under a different structure, i.e. for a project "search", I only wants to include "search" package. These exclusion is quite easy to accomplished using sonar.exclusion properties. My question, though, is how about the test? how can I exclude some of the packages? Because from my testing, even though my source and test folder are using the same structure, the test packages are not automatically excluded when I specified "sonar.exclusions".
my folder structure:
/src/com/domain/
-- search/
-- utils/
-- pooling/
-- category/
/test/src/com/domain/
-- utils/
-- pooling/
Sonar properties:
<property name="sonar.sources" value="${path}/src" />
<property name="sonar.tests" value="${path}/test/src" />
<property name="sonar.exclusions" value="com/domain/utils/**/*,com/domain/pooling/**/*,com/domain/category/**/*" />
So, I am trying to only include the "search" package. The code above works in a way that it causes SONAR to only analyze my "search" package. This package can be seen in the SONAR "Components" tab. Unfortunately, in addition to the "search" component, I can also see the "util" and "pooling" components. I have done some testing and certain that these two components (utils and pooling) are the result of "sonar.tests" properties. Just a note though, even though "util" and "pooling" shows up in components, SONAR shows zero files under both of them. So going back to my question, is there anyway that I can do to exclude "util" and "pooling" from showing up under "Components"? Maybe using properties (i.e. sonar test exclusions)?
Btw, I am using SONAR 2.11 and is running under Red Hat linux. I'm using SONAR-TASK 1.2.
Any help is welcomed and appreciated! Thanks!
You can define exclusions in the Configurations for the project directly in sonar.
From the documentation:
Since version 3.3, it is also possible to:
Exclude tests file from being analyzed:
go to Configuration > Settings > Exclusions and set > the sonar.test.exclusions property
The trick is:
sonar.exclusions: excludes files from sources directory (i.e.sonar.sources), it has no effect on tests directory.
sonar.test.exclusions: excludes files from tests directory (i.e.sonar.tests), it has no effect on sources directory.
See https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus
And, Using sonar.test.exclusions with Sonarqube 6.3
When I try to build my project, I get the following error:
error : Unable to update the AssemblyFileVersion for c:\builddir\MyProject\AssemblyInfo.cs: No stub entry for AssemblyFileVersion was found in the AssemblyInfo file.
I found this article, which implies that a "stub" property is required. So, in my AssemblyInfo.cs, I tried to specify one:
[assembly: AssemblyFileVersion("1.0.0")]
However, it isn't recognised. I finally came across this article, which says that you can't use the AssemblyFileVersion property with the CF. The targets file used by the build script is also used for building other, non CF projects, and needs to update the FileVersion for them.
Is it possible to put something in the AssemblyInfo.cs file, the target file or the build script that stops this from being an issue?
Yes, something like this:
#if !(WindowsCE || PocketPC)
[assembly: AssemblyFileVersion("1.0.0")]
#endif
If using the preprocessor in the manner described in the other answer doesn't work for you, consider putting the AssemblyFileVersion attribute into a separate source file, and conditionally including that source file in the project:
<Compile Include="AssemblyInfo.cs" />
<Compile Include="AssemblyInfo.AssemblyVersion.cs"
Condition="
'$(TargetPlatform)' == 'WindowsCE' OR
'$(TargetPlatform)' == 'PocketPC'"
/>
I'm not sure if there is already a property you can use in the project file, or if you would need to declare your own (perhaps $(Platform) is used for this?)
This will hopefully be an easy one. I have an F# project (latest F# CTP) with two files (Program.fs, Stack.fs). In Stack.fs I have a simple namespace and type definition
Stack.fs
namespace Col
type Stack=
...
Now I try to include the namespace in Program.fs by declaring
open Col
This doesn't work and gives me the error "The namespace or module Col is not defined." Yet it's defined within the same project. I've got to be missing something obvious
What order are the files in the .fsproj file? Stack.fs needs to come before Program.fs for Program.fs to be able to 'see' it.
See also the start of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!444.entry
and the end of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!347.entry
I had the same problems, and you are right, the order of the files is taken in account by the compiler. Instead of the Remove and Add pattern, you can use the Move Up / Move Down items in the context menu associated to the .fs files. (Alt-Up and Alt-Down are the shortcut keys in most of the standard key-bindings)
All of the above are correct, but how to do this in VS2013 is another question. I had to edit my .fsproj file manually, and set the files in exact order within an ItemGroup node. In this case it would look like this:
<ItemGroup>
<Compile Include="Stack.fs" />
<Compile Include="Program.fs" />
<None Include="App.config" />
</ItemGroup>
I had the same issue and it was indeed the ordering of the files. However, the links above didn't describe how to fix it in Visual Studio 2008 F# 1.9.4.19.
If you open a module, make sure your source file comes after the dependency in the solution explorer. Just right click your source and select Remove. Then re-add it. This will make it appear at the bottom of the list. Hopefully you don't have circular dependencies.
I'm using Visual Studio for Mac - 8.1.4 and i've noticed that some .fs files are not marked as "Compile". You can see this by Viewing Build Output and see if all your files are there and in the correct order.
I've had to manually make sure certain files are marked with "Compile", and have had to move them up and down manually until it "takes".
I have got the following structure:
$
--TeamProject1
---Solution1.sln
----TestProject1
--TeamProject2
---Solution2.sln
----TestProject2
In TestProject1, I add TestProject2.dll as reference (Not a project reference, but a file reference). My question is: how to build a solution that reference to assemblies belonging to different team project?
I have got TFSBuild.proj file containing the following info:
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../DEV/TeamProject1.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
<Map Include="$/TeamProject1">
<LocalPath>$(SolutionRoot)</LocalPath>
</Map>
<Map Include="$/TeamProject2">
<LocalPath>$(SolutionRoot)</LocalPath>
</Map>
<Target Name="BeforeGet">
<DeleteWorkspaceTask TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Name="$(WorkspaceName)" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workspace /new $(WorkspaceName) /server:$(TeamFoundationServerUrl)" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workfold /unmap /workspace:$(WorkSpaceName) "$(SolutionRoot)"" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) "%(Map.Identity)" "%(Map.LocalPath)"" />
</Target>
Thanks in advance.
Xiaosu
To quote the official TFS guide on CodePlex:
If you share source or binaries across team projects, you have two options:
Branching. With this approach, you branch the source from the other team project into your current solution. This creates a configuration that unifies the source from the shared location and your project on the server-side.
Workspace Mapping. With this approach, you map the source from the other team project into a workspace on your development computer. This creates a configuration that unifies the source from the other team project and your project on the client-side.
Branching is the preferred approach because it stores the dependency relationship on the source control server. Workspace mapping is a client-side-only approach, which means that you and every developer must create the mapping on your own computers and also on the build server in order to successfully build the application.
Branching adds additional merge overhead but it enables you to make the decision to pick up updated binaries or source more explicitly.
AFAIK this is not possible and it will be problematic on developer's machines. File references is the way to go. I usually organize projects like this:
$
-- TeamProject1
-- branches
-- trunk
Solution1.sln
-- lib
TestProject2.dll
-- src
-- test
TestProject1.csproj references TestProject2.dll from lib
-- TeamProject2
-- branches
-- trunk
Solution2.sln
-- lib
-- src
-- test
TestProject2.csproj
This way TeamProject1 is independent from the source code of TeamProject2 and it contains all the necessary dependencies. If TeamProject2 changes it won't necessary break TeamProject1.
It was very difficult to find the actual answer for this and it wasted a lot of my time. So if you ever get this problem, here is a link to the correct solution
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9918911f-5951-43be-9ee9-00214cf17400/buildvnext-and-multiple-team-projects?forum=tfsbuild
Basically the UI does not allow you to select more than one team project on your collection. But you can always type the actual path to your other team projects and it will work