Projects and Solutions
VS C/C++
.Net SDk structure / setup
Multi-project solutions
Compiling C code with VS.Net
Configuration Macros
C++ Using and Creating DLL
Using MS.Net Test Projects
Configuring DB for Test Project
Adding new Solution or Project to Team Foundation Server source control
Branching and Merging using TFS
Projects and Solutions
=======================
In CVF (and Visual C++ 6.0), “projects” were placed in “workspaces.”
A CVF workspace was little more than a container for one or
more projects and was not involved in the build process. A project
built something (an EXE, LIB or DLL ile in most cases), and it
could contain both Fortran and C code. One project was always
designated as “active.”
In Visual C++ .NET, projects are substantially the same, but a
project can be associated with only one language. For example,
if you add C iles to a Fortran project, the C iles will be ignored.
A solution holds multiple projects, but it is different from a
workspace because you can build a solution, which builds all of the
contained projects in a speciied, user-conigurable order.
When you have a mixed Fortran and C application, you must put the Fortran
code into a Fortran project and the C code into a C (or C++)
project. The projects are built separately and then, if appropriate, they
are linked together. If the old project was a static library, two static
library projects are created, with the objects going into a combined .LIB
file. In this case, it does not matter which project you select as
being the “main” project.
VS C/C++
=========
C/C++ program are stored in
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7
this contains the bin\cl.exe and include directories etc.
to compile: eg.
cl /clr /Zi -c -o -DVAR file.c { -> file.obj }
/clr - tells compiler to create managed code
/Zi - for debugging
.Net SDk structure / setup
============================
%PATH%=%MSNET_C%\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
%MSNET_C%=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7
%MSNET_C_LIB%=
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib;
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Lib
Include Files:
Multi-project solutions
========================
When building a solution, it can be necessary to build certain projects first,
to generate code used by other projects. When a project consumes executable code
generated by another project, the project that generates the code is referred to
as a project dependency of the project that consumes the code. Such dependency
relationships can be defined in the Project Dependencies dialog box.
To assign dependencies to projects
(Your solution must consist of more than one project before you can create project dependencies.)
-> In Solution Explorer, select a project.
-> On the Project menu, choose Project Dependencies.
Compiling C code with VS.Net
================================
1. Create a Visual C++ project as usual.
2. Write a *.c code in the C language.
3. Remove all other automatic source files that were created; eg stdafx.h
3. Remove Precompiled Header usage
Project -> Properties -> C/C++ -> Precompiled headers -> Create/Use Precompiled Headers = None
99 Errors:
Message: "fatal error C1010: unexpected end of file while looking for precompiled header directive "
Cause: You defined your project to use precompiled header files. So your c file or cpp files must include
the file that is defined for precompilation at the top of it.
Solution: Remove the use of precompiled headers. Select the file in the solutin explorer. Click on properties. Select the C++ options. Choose precompiled Headers. Select none.
Configuration Macros
=====================
$(ConfigurationName), eg Debug or Release or etc...
$(TargetDir)
C++ Using and Creating DLL
===========================
Ref: Visual C++
Walkthrough: Creating and Using a Dynamic Link Library
http://msdn.microsoft.com/en-us/library/ms235636(VS.80).aspx
Creating the DLL project
1. Add New Project -> Visual C++ / Win32 -> Win32 Project ->
Application Type: DLL
Additional Options: Export Symbols
2. Add prototype in header files
3. Add source code in cpp files
WARNING: DLL and LIB are created in the debug / release directory UNDER SOLUTION DIR.
Creating the driver project
1. Create a C++ console application or other executable project
2. Project Properties -> C++ -> General -> Additional Include Directories -> $(SolutionDir)
3. Project Properties -> Linker -> General -> Additional Library Directories -> $(SolutionDir)
3. Project Properties -> Linker -> Input -> Additional Dependencies ->
Using MS.Net Test Projects
===========================
Ref: MS VS.Net Documentation:
i) Development Tools and Technologies -> Visual Studio Team System -> Team Edition For Developers -> Working with Unit Tests
ii) Development Tools and Technologies -> Visual Studio Team System -> Team Edition For Testers
A) Setting Up Configuration File. This section shows how to create an app.config file and add settings for
i) defining Database connections for Data-Driven Unit Tests.
- Right click project -> Add -> New Item -> Application Configuration File.
- Add this line to the app.config, within the
name="microsoft.visualstudio.testtools"
type="Microsoft.VisualStudio.TestTools.UnitTesting.TestConfigurationSection, Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
/>
- For Database connection strings, after the
- For Database details, after the connectionStrings element, create a microsoft.visualstudio.testtools element. Then add this element:
Example of testcode using the Database connection created above.
using Microsoft.VisualStudio.TestTools.UnitTesting;
........
[TestMethod()]
[DeploymentItem("MyTestProject\\testdatasource.mdb")]
[DataSource("MyJetDataSource")]
public void MyTestMethod()
{
int a = Int32.Parse(context.DataRow["Arg1"].ToString());
int b = Int32.Parse(context.DataRow["Arg2"].ToString());
Assert.AreNotEqual(a, b, "A value was equal.");
}
[TestMethod()]
[DeploymentItem("MyTestProject\\data.xls")]
[DataSource("MyExcelDataSource")]
public void MyTestMethod2()
{
Assert.AreEqual(context.DataRow["Val1"], context.DataRow["Val2"]);
}
B) Structure of Unit Tests
Microsoft.VisualStudio.TestTools.UnitTesting -> namespace of Unit Tests.
[TestMethod()], [TestClass()] -> attributes for the unit test method and its class.
[TestInitialize()] -> Use this on a method that does some initialization, eg prepare data, for the tests.
[TestCleanup()] -> Use this to clean up things, do not use finalizer method.
TestContext property -> contain information of the test.
Assert Statements -> lets developer specify or assert the things that needs to be tested, eg AssertEqual
ExpectedExceptionAttribute -> used to verify that a particular exception is thrown.
C) Test Run Configuration
This control the test runs and lets the user specify various properties related to:
General, Controller and Agent, Code Coverage, Deployment, Hosts (ASP.Net), Setup and Cleanup Scripts, Test Timeouts, Web Test
i) Note that Test Run Configuration belong to the Solution, not Project, but there can be
multiple of them, with different names ending in *.testrunconfig.
ii) To add new Test Run Configuration: in Solution Explorer -> Solution Items -> Add -> New Item -> Categories ->
Test run configuration -> add details......
iii) To specify which of multiple configurations to run, or just to edit it:
go to Test menu -> Select Active Test Run Configurations
go to Test menu -> Edit Test Run Configurations
Configuring DB for Test Project
=================================
Download SQLExpress Management Studio Express from:
http://www.microsoft.com/downloads/details.aspx?FamilyId=C243A5AE-4BD1-4E3D-94B8-5A0F62BF7796
Here’s a page which compares Express and non-Express versions:
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
Create DB:
- Open MSSQL Server Management Studio Express; create a DB, say forTestProject
Configure DB:
- Open: Start -> MSSQL Server 2005 -> Configuration Tool -> SQL Server Configuration Manager.
- In the SQL Server Configuration Manager:
SQL Server 2005 Network Configuration -> Protocols for SQLEXPRESS -> Enable (Shared Memory, Named Pipes, TCP/IP)
Restart Service
Connecting a function to DB:
- After adding the prototype or shell for Unit Testing a function / method, go to Test Manager.
- Right click on the Test Name of the list of tests in Test Manager.
- In the Properties window of that tests, click on DataConnectionString and Data TableName respectively to fiil in details.
- The Attribute [DataSource(...)] will automatically appear in the code, when the above Properties windows are filled.
Adding new Solution or Project to Team Foundation Server source control
=========================================================================
Prerequisites:
1. Visual Studio project exist already, say project ProjA under solution SolnA.
2. Team Foundation Server exist, server name = "aTFS", TFS project name = "TFSproj"
Process to create a new connection between VS project and TFS source control.
1. Open VS and go into ProjA.
2. File - Source Control - Open Source Control
3. Click servers button and enter name of server, eg "aTFS"
4. In the list of Team Projects, select the TFS project (eg TFSproj) where you wish to place ProjA.
5. Click cancel to get out of the dialog boxes.
6. Back in the Solution Explorer, right click on the Solution and select "Add Solution to Source Control".
7. In the new dialog, choose the path in TFS eg. TFSproj.
Branching and Merging using TFS
=================================
The concept of branching and merging is simple but the mechanics of using TFS for branching and merging need to be understood carefully because it is prone to errors when users misses a step. Quick advice, practice branching and merging a few times with test projects before using it on your real project.
This section will outline a step by step walkthrough of the Branch-Merge process using TFS. But before the walkthrough, please go through the pre-requisites here and be thoroughly familiar before moving on.
Pre-requisites:
1. Read the official documentataion (this is not enough, but still need to be familiar with) at:
MSDN Library - Development Tools and Languages - Visual Studio Team System - Team Foundation - Team Foundation Project Members -
Working with Team Foundation Source Control - Branching and Merging Team Foundation Source Control.
2. Be familiar with Solution Explorer in Visual Studio (VS) - if not shown then access from View menu. Understand that Solution Explorer shows the LOCAL version of your code.
3. Know how to check-out and check-in projects between Local workspace and TFS server. This is another big area which you need to fully understand.
4. Be familiar with Source Control Explorer. This is a client to view your files that are stored in the TFS server. This is a server view of files on the server - they are not your local files.
5. Change Source Control. This is a crucial tool to check that your projects are in sync between LOCAL versions and TFS server versions. Access this by highlighting a project in Solution Explorer, then go to File - Source Control - Change Source Control.
Note that if the project is not in source control, then the link above will be: File - Source Control - Workspaces.
6. There is an existing project (create one if needed) called Test_BranchMerge in a Solution of your choice. This Solution and its project should be in your local PC and in the TFS server and is properly checked-in and the source control path properly synchronized (can be checked using Change Source Control - see step 5 above). In this project, there should be at least one source file, eg Source1.f90. This example project is a Fortran project, but it should apply to other projects recognized by VS.
Walkthrough of Branching and Merging:
1. Go to Solution Explorer and click on the Test_BranchMerge project. Check the following: i) On the Pending Change column, there is nothing pending. ii) in the Latest column, everything is Yes. iii) In the Local Path above, the path is pointing to the correct local folder.
2. BRANCH - In the Solution Explorer, right click on Test_BranchMerge project; select Branch. In the Branch dialog:
i) in the Target field, you change the last part of the name, but do not alter the other parts of the path. Example:
Target: $/aaa/bbb/ccc/ddd/Test_BranchMerge-branch
this can be changed to
Target: $/aaa/bbb/ccc/ddd/Test_BranchMerge-06
but do not change the server structure $/aaa/bbb/ccc/ddd
ii) Branch from Version: select Latest Version.
iii) Check the box "Create local working copies for the new branch.
iv) Click OK.
This process will create a branch in the TFS server as well as a copy of the project in your local directory under the same solution as the original project source.
3. VERIFY -
i) In Windows File Explorer (not in VS), the folder Test_BranchMerge-06 exist on the same level as Test_BranchMerge. All contents between these two folders should be identical.
For Advanced Users: the project files *.cproj (for C#), *.vfproj (for Fortran) which identifies the projects to VS are identical between Test_BranchMerge-06 and Test_BranchMerge. This means all systems including VS (except for TFS) will REGARD these two projects as IDENTICAL. In VS, Test_BranchMerge-06 will be recognized as Test_BranchMerge. This is the correct feature and effect we need for branching. See step 4 in using this new branch to work with.
ii) In the VS - Source Control Explorer, Test_BranchMerge-06 is visible on the Directory Tree on the same level as Test_BranchMerge, with a branching symbol next to it. Click on Test_BranchMerge-06 on the left pane and on the right pane, all the contents Test_BranchMerge-06 are visible. All contents have the branching symbol next to it. In the Pending Change column, all contents have state - branch.
iii) In the Solution Explorer, check that the Test_BranchMerge project is still visible. Note that this shows the local Solution which is still linked to the local source of the original Test_BranchMerge project. This will be re-connected manually in step 4. Click to highlight Test_BranchMerge project in Solution Explorer, then go to File - Source Control - Change Source Control. View that the Test_BranchMerge project has Server Binding pointing to $/aaa/bbb/ccc/ddd/Test_BranchMerge. Do not change anything. Click OK.
iv) Again highlight Test_BranchMerge in Solution Explorer, then look at the Properties Window (if not show, go to View menu).
Verify that the project path is still pointing to Test_BranchMerge folder in your local PC.
4. INITIAL CHECK-IN
This step is necessary if we want to work on the changes in the branched code. At the end of Step 2, although the branched project and source has been created in TFS and the local PC, it HAS NOT BEEN REGISTERED UNDER TFS.
i)In the Source Control Explorer, in the left pane, right click on Test_BranchMerge-06 and select: Checkin Pending changes.
ii) Verify - Look in the right pane, under the Pending Changes column and check that all the files under Test_BranchMerge-06 has NO pending status at all; ie. the branching symbols and branch pending status are gone.
At this stage, the new branch for the project has been cloned.
5. RE-CONNECT VS Solution to point to the new Branch.
At this stage, VS Solution is still connected to Test_BranchMerge folder locally.
i) Go to Solution Explorer, right click on Test_BranchMerge and select Remove.
ii) In the Solution Explorer, right click on the Solution (at the top) and select Add - Existing Project.
iii) In the dialog box that appears, navigate to Test_BranchMerge-06 folder on your local PC and select Test_BranchMerge.vfproj or Test_BranchMerge.csproj, etc... and click Open. Note that the project file is STILL named Test_BranchMerge.xxxx, not Test_BranchMerge-06.xxxx.
6. VERIFY - that the new branch is connected.
i) From the Solution Explorer, highlight the project Test_BranchMerge. In the Properties Window, check that the Project Path is pointing to the local folder Test_BranchMerge-06.
ii) From the Solution Explorer, highlight the project Test_BranchMerge. Go to File - Source Control - Change Source Control. Looking at the project Test_BranchMerge - check that its Server Binding is set to $/aaa/bbb/ccc/ddd/Test_BranchMerge-06. Check that the Connected box is ticked and the Status is Valid.
This shows that for all intent and purposes, the branch is now recognized as the Test_BranchMerge project (not Test_BranchMerge-06). The paths to the server and local PC shows that the project is linked to the correct branch folder Test_BranchMerge-06.
7. WORK IN THE BRANCH
In the VS environment, modify the code, run the program, do whatever as normal. The Test_BranchMerge project should work as usual before branching. Even the Check-in proces to TFS should work as normal. As noted before, the source code is now connected to the branched version Test_BranchMerge-06, both locally and on TFS.
i). In the Solution Explorer, in the Test_BranchMerge project, open up the file Source1.f90. Edit this file, save it.
ii). Note the TFS locked symbol next to Source1.f90 changed to the red tick symbol indicating that the code is updated and different to the TFS version.
iii). If the red-tick edit symbol does not appear, then in Solution Explorer, click on Source1.f90, select Check-out for Edit. Then edit the code and save.
iv). Once all code changes are done, click on the Test_BranchMerge project in Solution Explorer and select Check In.
8. MERGE - like branching, merging must be done via Source Control Explorer. Branch - Merge are TFS operations, they are not VS operations.
i) From the Source Control Explorer, right click on the Test_BranchMerge-06 project, and select Merge.
ii) In the Merge dialog, choose the following:
Source Branch: $/aaa/bbb/ccc/ddd/Test_BranchMerge-06
Select: All changes up to a specific version
Target Branch: $/aaa/bbb/ccc/ddd/Test_BranchMerge
iii) Click Next, choose Latest Version as the Version Type, click Next, click Finish.
Note the merging occurs between code in TFS server, not your local version. Hence before merging, both old and new branch must be fully checked in. Also note merging occurs from Branched version as Source to Target original version.
iv) Verify - in the Source Control Explorer, click to highlight the original project Test_BranchMerge. Looking at the right pane under the Pending Change column, note that the files which has been changed will now have the "merge, edit" status.
v) Checkin - in the Source Control Explorer, right click Test_BranchMerge and select Checkin Pending Changes.
vi) Verify - if checkin is successful, then the files with "Merge, Edit" Pending Changes (step iv) above) will now have NO pending change status.
9. CONTINUING WORK
In VS, remember that the Test_BranchMerge project is still linked to the branched version Test_BranchMerge-06 code base. The user now has many options such as:
i) Continue working with the Test_BranchMerge-06 branch. The user can keep on editing code in VS under the Test_BranchMerge project, with no extra re-configuration.
ii) Revert back to work with original branch (which now has the merged changes). In the Solution Explorer, remove the Test_BranchMerge project (which is actually the Test_BranchMerge-06 branch). Then click on Solution in the Solution Explorer and Add Existing Project; select the xxxx.xxproj file from Test_BranchMerge folder.
iii) Work from a totally new branch, eg using a new branch Test_BranchMerge-07. To do this, repeat the whole process from Step 1.
There may be variations of how the branch-merge process can be done; the walk-through shown above is just one scenario that should just work without having to spend more time investigating an error prone process.
Posts
