SolutionDir vs. ProjectDir

Feb 2, 2008 at 9:20 PM
Currently in Microsoft.SharePoint.targets, <Target Name="DebugBuild"> has the line:
<Exec Command="$(STSDEV) /refresh $(TargetName) $(SolutionDir)" ContinueOnError="true" />

Maybe it is better to be
<Exec Command="$(STSDEV) /refresh $(TargetName) $(ProjectDir)" ContinueOnError="true" />

The other issue is that, if there is a space in the Dir, it won't build.


Developer
Feb 20, 2008 at 6:04 PM
Our development team made the same change from the $(SolutionDir) to $(ProjectDir) because we found that if you had multiple StsDev projects in a single solution that some were not building correctly.
Feb 25, 2008 at 8:33 PM
ditto.
Developer
Mar 14, 2008 at 7:35 PM
We did the same thing and worked great.
Mar 17, 2008 at 10:41 PM
@dmcwee: "we found that if you had multiple StsDev projects in a single solution that some were not building correctly"

How did you create a Solution with multiple STSDev projects? Copy/Paste? Add Existing Project?

Not to look the gift horse too closely in the mouth (I love parts of this: reflection, keeping ddf and manifest synched up, etc.) but this strikes me as yet another "great for demo-ing, not quite ready for real-life" solution (kind of like VSeWSS). We at the very least need multi-project support before this becomes truly usable in a real-world environment..
Developer
Mar 18, 2008 at 4:31 AM

@austegard
How did you create a Solution with multiple STSDev projects? Copy/Paste? Add Existing Project?


Once you create a solution using stsdev add the additional projects you desire to that solution. File->Add->Existing Project...
Be aware that if you do this then whatever the build target is for the solution all projects will be built using that target. This can be a problem if you try to DebugDeploy a new solution that includes projects that are already deployed.


strikes me as yet another "great for demo-ing, not quite ready for real-life"

Actually our development team has been using this in a "real-life" project for our company and have really liked it. We have made, as you may have noticed from some of my other posts, some bug corrections in our version of the stsdev tool (we are trying to provide back to the community but cannot contribute to this project yet) which have enabled "real-life" development.

One nice element especially for the "real-life" use, and something we did early in our adoption, is that you can create your own project type. To get the capability we wanted we did customize some of the stsdev code to allow greater control the the project, but it has allowed our team to develop a common look for all our deployed features and webparts (grouping, icon, etc) and has saved us a lot of tedious work.
Apr 10, 2008 at 6:53 PM
I agree that it should be ProjectDir since it is common to have the solution file in your top level folder for the solution and each project in its own sublevel folder under that.

I've tried multi project support and am unable to reference any of my other projects in my solution from the "stsdev" project. None of the other projects show up under the Add Reference dialog in the Projects tab. Is there a way to fix this?
Apr 23, 2008 at 4:49 PM
Edited Apr 23, 2008 at 4:50 PM

yysun wrote:
The other issue is that, if there is a space in the Dir, it won't build.


Try adding &quot; before $(ProjectDir):
<Exec Command="$(STSDEV) /refresh $(TargetName) &quot;$(ProjectDir)" ContinueOnError="true" />

Works for me, but YMMV.