TFS Build and Database Projects

[Steve Barker]

Hi all,

I have a solution in a Team Project, with a Team Build configured. The
solution contains a database project.

The database project compiles fine on my development machine, but the build
server is hitting an error:

(0,0): error TSD257: The value for $(DefaultDataPath) is not set,
please set it through the build property page.

Apparently, this is to do with the build server not knowing the details of
the SQL Server, as explained in this link:

http://blogs.msdn.com/buckh/archive/2007/09/11/vsts-2005-and-2008-building-database-projects-with-team-build.aspx

I have tried to follow the advice in the link, but I still get the error.
Does anyone have any ideas how I can fix this?

Thanks,

Steve.

[Hongye Sun [MSFT]]

Hi Steve,

Thanks for your post.

I had the same error before. I fixed it by following #2 method by modifying
TFSBuild.rsp file. (However, it is not a perfect solution to this)

Which method you are taking? There is possibilities that if you take #1 or
#3 method but did not check in the .user file, the build agent cannot get
the file. .user file, by default, will not be automatically checked in
source control.

Please check if the user file is in the source control and have a try of #2
method. Thanks.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.
 
This posting is provided "AS IS" with no warranties, and confers no rights.

[Steve Barker]

Hi Hongye,

Yes, issue #2 looked like the way to go. I started with the approach
involving $(MSProjectFile).teambuild.user, but I couldn't get this to work.
I've just copied the settings from the <ProjectName>.dbproj.user file into
the <ProjectName>.dbproj file, and it is now working.

For future reference, what does $(MSProjectFile).teambuild.user actually mean?

Thanks,

Steve.

Post by Hongye Sun [MSFT]
Hi Steve,
Thanks for your post.
I had the same error before. I fixed it by following #2 method by modifying
TFSBuild.rsp file. (However, it is not a perfect solution to this)
Which method you are taking? There is possibilities that if you take #1 or
#3 method but did not check in the .user file, the build agent cannot get
the file. .user file, by default, will not be automatically checked in
source control.
Please check if the user file is in the source control and have a try of #2
method. Thanks.
Regards,
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hongye Sun [MSFT]]

Hi Steve,

Thanks for your reply.

$(MSProjectFile).teambuild.user file is a user file, which contains user
settings in Visual Studio. The settings is specific to every user. For
example: DefaultDataPath is usually different for different users in
different machines. The user file should not be checked into source control
in most cases, because everyone need to change this file after get it from
source control.

However, $(MSProjectFile).teambuild.user file here is not a really user
file because of its name is not ended with dbproj.user. Visual Studio will
not load it automatically. As a result, it can be put into the source
control and will not affect other users.

The purpose to put the file in source control is to let build server get it
and rename it by ending with dbproj.user file. The rename work is done in
the target file.
The target name is "RenameTeamBuildUserFile".

Then how does msbuild knows to load the target file? It has been done by
adding conditional import element in dbproj file.
-------------------------------
<Import Condition="'$(TeamBuildConstants)' != ''"
Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\TeamData\Micro
soft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets" />
<Target Name="BeforeBuild"
DependsOnTargets="$(BeforeBuildTeamBuildTargets)"></Target>
-------------------------------
It means when current is a team build then import
Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets file. Before
the build begin, run BeforeBuildTeamBuildTargets in that targets file.
Within that targets, it invokes renaming task.

Hope it helps you understand why we use teambuild.user file here.

Have a nice day.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.
 
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hongye Sun [MSFT]]

Hi Steven,

Here is what you replied in another post. It seems to be suitable to be
here:
--------------------------------------------------
Ah, OK. That explains it better. Thanks for your explanation. I guess the
problem with this solution is that it assumes all users have the same
settings.

When it says "$(MSProjectFile).teambuild.user", does that mean you have to
replace the "$(MSProjectFile)" bit with the name of the project? So if the
project is called TestApp, the file should be called
"TestApp.teambuild.user"?
--------------------------------------------------

The answer is yes. $(MSProjectFile) must be the project file's name. That
is because in the
Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets file. It
defines the same name. If they are different, the targets file will not
find it.

In addition, for your guess "it assumes all users have the same settings.".
It is half right. Because all users have the same teambuild.user settings,
however, the setting file is not used by the users because Visual Studio
doesn't know about teambuild.user file. Instead, every user can have his
own dbproj.user file, which can be acknowledged by Visual Studio. So the
target for the author to add the teambuild.settings is because it will not
affect all users' development environment and it makes the settings of team
build can be source controled.

Please let me know if you have any confusion here. I will try my best to
clarify them. Thanks.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.
 
This posting is provided "AS IS" with no warranties, and confers no rights.

[Steve Barker]

Thanks. That's fine.

The main thing is I've got the database build working now...

Post by Hongye Sun [MSFT]
Hi Steven,
Here is what you replied in another post. It seems to be suitable to be
--------------------------------------------------
Ah, OK. That explains it better. Thanks for your explanation. I guess the
problem with this solution is that it assumes all users have the same
settings.
When it says "$(MSProjectFile).teambuild.user", does that mean you have to
replace the "$(MSProjectFile)" bit with the name of the project? So if the
project is called TestApp, the file should be called
"TestApp.teambuild.user"?
--------------------------------------------------
The answer is yes. $(MSProjectFile) must be the project file's name. That
is because in the
Microsoft.VisualStudio.TeamSystem.Data.TeamBuildTasks.targets file. It
defines the same name. If they are different, the targets file will not
find it.
In addition, for your guess "it assumes all users have the same settings.".
It is half right. Because all users have the same teambuild.user settings,
however, the setting file is not used by the users because Visual Studio
doesn't know about teambuild.user file. Instead, every user can have his
own dbproj.user file, which can be acknowledged by Visual Studio. So the
target for the author to add the teambuild.settings is because it will not
affect all users' development environment and it makes the settings of team
build can be source controled.
Please let me know if you have any confusion here. I will try my best to
clarify them. Thanks.
Regards,
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hongye Sun [MSFT]]

You are welcome, Steve. I am very glad that the issue has been fixed.

If you need any further help, please feel free to let us know. You are
always welcome to our newsgroup service. Have a nice day.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.
 
This posting is provided "AS IS" with no warranties, and confers no rights.