469,946 Members | 1,805 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,946 developers. It's quick & easy.

MSBuild & Specialized build file

Al
Hi all

We have created a xml file that imports a single project using the Import
element. This project compiles to a class library, but has references to two
other projects that are also class libraries. We are having a path reference
issue for the depending projects; if the build is started in another
directory than that of the imported project. (It's a simple cannot find
project xyz.csproj, build fails.) If we place the xml file in the same
directory as the imported project and update the path for the value of being
used, it builds fine. We cannot simply use the solution as it also has a Web
Service and Web Site, which are not required to be built at all.

Any thoughts would be great!
Thanks.
May 3 '06 #1
5 4166
Hi,
It sounds like you are saying that you are importing a project file into
another, and the imported project has some relative paths declared in it. If
that is the case then your scenario will not work out of the box. MSBuild
will use the path of the entry project file to resolve locations to items.
There is a way to achieve this, you need a custom task. I've written about
how to achieve this at:
http://www.sedodream.com/PermaLink,g...c157eb2b4.aspx
If I mis-understood your problem let me know.

Sayed Ibrahim Hashimi
www.sedodream.com

"Al" wrote:
Hi all

We have created a xml file that imports a single project using the Import
element. This project compiles to a class library, but has references to two
other projects that are also class libraries. We are having a path reference
issue for the depending projects; if the build is started in another
directory than that of the imported project. (It's a simple cannot find
project xyz.csproj, build fails.) If we place the xml file in the same
directory as the imported project and update the path for the value of being
used, it builds fine. We cannot simply use the solution as it also has a Web
Service and Web Site, which are not required to be built at all.

Any thoughts would be great!
Thanks.

May 4 '06 #2
Al
I would say that sounds like the problem, relative path issue from the mail
build file. But just in case here is teh contents of the file in its
simplist form:

<project DefaultTargets=Build>
<UsingTask TaskName="our.custom.task.dosomething"
AssemblyFile="c:\temp\our.custom.task.dll" />
<Import Project=".\ourprojectdir\outprojectfile.csproj" />
<Target Name="AfterBuild">
<dosomething PropertyA="somevalue" />
</Target>
</project>

This basic file would be at teh root level with the solution file and is
named build.xml. It is NOT part of the solution. Open a command prompt, go
to the dir with the xml file in it, and simply type "msbuild build.xml" (and
the framework is on the path so msbuild will run). It imports the project
fine, and starts checking the references for the project so it can build any
outstanding references. It finds the first one, which is another project in
the solution at the same level at the imported project
(.\ourotherprojectdir\ourotherprojectfile.csproj). It bombs saying it cannot
find the project file. And I fully understand the path issue, but other than
editing the project file I do not see a way to overcome this. I guess a
custom task would work, where it takes the first project name as a value and
starts the process, but that seems clugy. Other thoughts?

Thanks.

"Sayed Ibrahim Hashimi" wrote:
Hi,
It sounds like you are saying that you are importing a project file into
another, and the imported project has some relative paths declared in it. If
that is the case then your scenario will not work out of the box. MSBuild
will use the path of the entry project file to resolve locations to items.
There is a way to achieve this, you need a custom task. I've written about
how to achieve this at:
http://www.sedodream.com/PermaLink,g...c157eb2b4.aspx
If I mis-understood your problem let me know.

Sayed Ibrahim Hashimi
www.sedodream.com

"Al" wrote:
Hi all

We have created a xml file that imports a single project using the Import
element. This project compiles to a class library, but has references to two
other projects that are also class libraries. We are having a path reference
issue for the depending projects; if the build is started in another
directory than that of the imported project. (It's a simple cannot find
project xyz.csproj, build fails.) If we place the xml file in the same
directory as the imported project and update the path for the value of being
used, it builds fine. We cannot simply use the solution as it also has a Web
Service and Web Site, which are not required to be built at all.

Any thoughts would be great!
Thanks.

May 4 '06 #3
Hi,
Actually in your situation this doesn't seem to be the problem. When you
import a project file, relative paths are evaluated correctly for the Using
task and the Import task. The problem is when you declare Items in your
imported project that use relative paths. In your case I'm not sure what the
problem is. It sounds like you are creating something like a solution file
with your build.xml is this right? If this is the case then one thing you may
want to consider is to let MSBuild actually create the MSBuild version of the
solution file. When MSBuild is building a solution file it will create an
MSBuild compatable version of the solution in memory to be consumed by
MSBuild. In order to have this file written out to disk you'll have to set
the envrionment variable msbuildemitsolution to the value of 1. Then that
file will be written to disk. If nothing else you can have a look at the file
and tweak your build.xml file. I've written about how you can customize your
solution level build using MSBuild by taking advantage of this fact. Its kind
of advanced, but you can read about it at:
http://www.sedodream.com/PermaLink,g...aa24bc7da.aspx

Sayed Ibrahim Hashimi
www.sedodream.com
"Al" wrote:
I would say that sounds like the problem, relative path issue from the mail
build file. But just in case here is teh contents of the file in its
simplist form:

<project DefaultTargets=Build>
<UsingTask TaskName="our.custom.task.dosomething"
AssemblyFile="c:\temp\our.custom.task.dll" />
<Import Project=".\ourprojectdir\outprojectfile.csproj" />
<Target Name="AfterBuild">
<dosomething PropertyA="somevalue" />
</Target>
</project>

This basic file would be at teh root level with the solution file and is
named build.xml. It is NOT part of the solution. Open a command prompt, go
to the dir with the xml file in it, and simply type "msbuild build.xml" (and
the framework is on the path so msbuild will run). It imports the project
fine, and starts checking the references for the project so it can build any
outstanding references. It finds the first one, which is another project in
the solution at the same level at the imported project
(.\ourotherprojectdir\ourotherprojectfile.csproj). It bombs saying it cannot
find the project file. And I fully understand the path issue, but other than
editing the project file I do not see a way to overcome this. I guess a
custom task would work, where it takes the first project name as a value and
starts the process, but that seems clugy. Other thoughts?

Thanks.

"Sayed Ibrahim Hashimi" wrote:
Hi,
It sounds like you are saying that you are importing a project file into
another, and the imported project has some relative paths declared in it. If
that is the case then your scenario will not work out of the box. MSBuild
will use the path of the entry project file to resolve locations to items.
There is a way to achieve this, you need a custom task. I've written about
how to achieve this at:
http://www.sedodream.com/PermaLink,g...c157eb2b4.aspx
If I mis-understood your problem let me know.

Sayed Ibrahim Hashimi
www.sedodream.com

"Al" wrote:
Hi all

We have created a xml file that imports a single project using the Import
element. This project compiles to a class library, but has references to two
other projects that are also class libraries. We are having a path reference
issue for the depending projects; if the build is started in another
directory than that of the imported project. (It's a simple cannot find
project xyz.csproj, build fails.) If we place the xml file in the same
directory as the imported project and update the path for the value of being
used, it builds fine. We cannot simply use the solution as it also has a Web
Service and Web Site, which are not required to be built at all.

Any thoughts would be great!
Thanks.

May 5 '06 #4
Al
I just read the posting from below and it is and interesting idea. I knew we
had to build a custom build file as we have multiple projects running at the
same time and there may be a solution for a framework, then other solutions
that pertain to that certain project. One interesting piece I would like to
see discussed, is when you get a mixed solution; example I have right now is
a solution that contains a web project (contains both a web site and web
services), a COM+ component, a Win32 client (to view the COM+ component for
support issues), a full Win32 App that references the web services and a
setup project for the Win32 App distribution. How do you see this kind of
solution playing out using your example? ANy thoughts on trappings that you
could run across?

"Sayed Ibrahim Hashimi" wrote:
Hi,
Actually in your situation this doesn't seem to be the problem. When you
import a project file, relative paths are evaluated correctly for the Using
task and the Import task. The problem is when you declare Items in your
imported project that use relative paths. In your case I'm not sure what the
problem is. It sounds like you are creating something like a solution file
with your build.xml is this right? If this is the case then one thing you may
want to consider is to let MSBuild actually create the MSBuild version of the
solution file. When MSBuild is building a solution file it will create an
MSBuild compatable version of the solution in memory to be consumed by
MSBuild. In order to have this file written out to disk you'll have to set
the envrionment variable msbuildemitsolution to the value of 1. Then that
file will be written to disk. If nothing else you can have a look at the file
and tweak your build.xml file. I've written about how you can customize your
solution level build using MSBuild by taking advantage of this fact. Its kind
of advanced, but you can read about it at:
http://www.sedodream.com/PermaLink,g...aa24bc7da.aspx

Sayed Ibrahim Hashimi
www.sedodream.com
"Al" wrote:
I would say that sounds like the problem, relative path issue from the mail
build file. But just in case here is teh contents of the file in its
simplist form:

<project DefaultTargets=Build>
<UsingTask TaskName="our.custom.task.dosomething"
AssemblyFile="c:\temp\our.custom.task.dll" />
<Import Project=".\ourprojectdir\outprojectfile.csproj" />
<Target Name="AfterBuild">
<dosomething PropertyA="somevalue" />
</Target>
</project>

This basic file would be at teh root level with the solution file and is
named build.xml. It is NOT part of the solution. Open a command prompt, go
to the dir with the xml file in it, and simply type "msbuild build.xml" (and
the framework is on the path so msbuild will run). It imports the project
fine, and starts checking the references for the project so it can build any
outstanding references. It finds the first one, which is another project in
the solution at the same level at the imported project
(.\ourotherprojectdir\ourotherprojectfile.csproj). It bombs saying it cannot
find the project file. And I fully understand the path issue, but other than
editing the project file I do not see a way to overcome this. I guess a
custom task would work, where it takes the first project name as a value and
starts the process, but that seems clugy. Other thoughts?

Thanks.

"Sayed Ibrahim Hashimi" wrote:
Hi,
It sounds like you are saying that you are importing a project file into
another, and the imported project has some relative paths declared in it. If
that is the case then your scenario will not work out of the box. MSBuild
will use the path of the entry project file to resolve locations to items.
There is a way to achieve this, you need a custom task. I've written about
how to achieve this at:
http://www.sedodream.com/PermaLink,g...c157eb2b4.aspx
If I mis-understood your problem let me know.

Sayed Ibrahim Hashimi
www.sedodream.com

"Al" wrote:

> Hi all
>
> We have created a xml file that imports a single project using the Import
> element. This project compiles to a class library, but has references to two
> other projects that are also class libraries. We are having a path reference
> issue for the depending projects; if the build is started in another
> directory than that of the imported project. (It's a simple cannot find
> project xyz.csproj, build fails.) If we place the xml file in the same
> directory as the imported project and update the path for the value of being
> used, it builds fine. We cannot simply use the solution as it also has a Web
> Service and Web Site, which are not required to be built at all.
>
> Any thoughts would be great!
> Thanks.

May 5 '06 #5
Hi,
To be honest I haven't looked at the solution file that is generated from a
solution that contains non-MSBuild projects. If you are having to do many
customizations between the build of each project specifically then you are
probably better off to continue your build.xml because you are able to inject
the necessary steps as needed manually, but its hard to say.

Sayed Ibrahim Hashimi
www.sedodream.com

"Al" wrote:
I just read the posting from below and it is and interesting idea. I knew we
had to build a custom build file as we have multiple projects running at the
same time and there may be a solution for a framework, then other solutions
that pertain to that certain project. One interesting piece I would like to
see discussed, is when you get a mixed solution; example I have right now is
a solution that contains a web project (contains both a web site and web
services), a COM+ component, a Win32 client (to view the COM+ component for
support issues), a full Win32 App that references the web services and a
setup project for the Win32 App distribution. How do you see this kind of
solution playing out using your example? ANy thoughts on trappings that you
could run across?

"Sayed Ibrahim Hashimi" wrote:
Hi,
Actually in your situation this doesn't seem to be the problem. When you
import a project file, relative paths are evaluated correctly for the Using
task and the Import task. The problem is when you declare Items in your
imported project that use relative paths. In your case I'm not sure what the
problem is. It sounds like you are creating something like a solution file
with your build.xml is this right? If this is the case then one thing you may
want to consider is to let MSBuild actually create the MSBuild version of the
solution file. When MSBuild is building a solution file it will create an
MSBuild compatable version of the solution in memory to be consumed by
MSBuild. In order to have this file written out to disk you'll have to set
the envrionment variable msbuildemitsolution to the value of 1. Then that
file will be written to disk. If nothing else you can have a look at the file
and tweak your build.xml file. I've written about how you can customize your
solution level build using MSBuild by taking advantage of this fact. Its kind
of advanced, but you can read about it at:
http://www.sedodream.com/PermaLink,g...aa24bc7da.aspx

Sayed Ibrahim Hashimi
www.sedodream.com
"Al" wrote:
I would say that sounds like the problem, relative path issue from the mail
build file. But just in case here is teh contents of the file in its
simplist form:

<project DefaultTargets=Build>
<UsingTask TaskName="our.custom.task.dosomething"
AssemblyFile="c:\temp\our.custom.task.dll" />
<Import Project=".\ourprojectdir\outprojectfile.csproj" />
<Target Name="AfterBuild">
<dosomething PropertyA="somevalue" />
</Target>
</project>

This basic file would be at teh root level with the solution file and is
named build.xml. It is NOT part of the solution. Open a command prompt, go
to the dir with the xml file in it, and simply type "msbuild build.xml" (and
the framework is on the path so msbuild will run). It imports the project
fine, and starts checking the references for the project so it can build any
outstanding references. It finds the first one, which is another project in
the solution at the same level at the imported project
(.\ourotherprojectdir\ourotherprojectfile.csproj). It bombs saying it cannot
find the project file. And I fully understand the path issue, but other than
editing the project file I do not see a way to overcome this. I guess a
custom task would work, where it takes the first project name as a value and
starts the process, but that seems clugy. Other thoughts?

Thanks.

"Sayed Ibrahim Hashimi" wrote:

> Hi,
> It sounds like you are saying that you are importing a project file into
> another, and the imported project has some relative paths declared in it. If
> that is the case then your scenario will not work out of the box. MSBuild
> will use the path of the entry project file to resolve locations to items.
> There is a way to achieve this, you need a custom task. I've written about
> how to achieve this at:
> http://www.sedodream.com/PermaLink,g...c157eb2b4.aspx
> If I mis-understood your problem let me know.
>
> Sayed Ibrahim Hashimi
> www.sedodream.com
>
> "Al" wrote:
>
> > Hi all
> >
> > We have created a xml file that imports a single project using the Import
> > element. This project compiles to a class library, but has references to two
> > other projects that are also class libraries. We are having a path reference
> > issue for the depending projects; if the build is started in another
> > directory than that of the imported project. (It's a simple cannot find
> > project xyz.csproj, build fails.) If we place the xml file in the same
> > directory as the imported project and update the path for the value of being
> > used, it builds fine. We cannot simply use the solution as it also has a Web
> > Service and Web Site, which are not required to be built at all.
> >
> > Any thoughts would be great!
> > Thanks.

May 5 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by minorguy | last post: by
reply views Thread by ME | last post: by
2 posts views Thread by Jonathan Kacprowicz | last post: by
1 post views Thread by Divided Sky | last post: by
7 posts views Thread by shapper | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.