$(ProjectRoot)

Developer
Mar 18, 2011 at 4:58 AM
Edited Mar 18, 2011 at 6:23 AM

I'm going to remove the dependencies on the ProjectRoot env var, in a step towards removing the 'run the environment.cmd in a shell which leaks env vars' setup step.  Just figured to give a heads up about what I'm working on so efforts don't have to be duplicated, and to see if anyone thinks it's actually a bad idea or knows offhand if there are going to be more difficult hurdles in this quest.

Basically I think this is important because having what seems like a 'hacky' setup affects the potential-new-contributor experience.  "Open the solution, compile, go" is worth striving for; when looking for volunteers to assist with a project, barrier to entry has to be small.

(Earlier I tried to set up the environment with my command shell of choice and launch StyleCop and it failed to build.  I thought I saw the environment.cmd verifies PowerShell can execute, but then actually running environment.cmd from PowerShell and opening the solution doesn't work because PowerShell doesn't normally leak env vars out of the script... it's misleading that the script looks for PowerShell but doesn't actually work itself when run in PowerShell.)

Coordinator
Mar 18, 2011 at 7:35 AM
Hi Karak
As soon as you have some time contact me directly and we will get it working for you. PROJECTROOT is used absolutely everywhere, solution, wix, tests etc. So that'll be a major change to remove that dependency. Are you using the new how to docs from the documentation tab on codeplex?
I've followed that process on 4 different Dev boxes and it works fine. Are you opening the cmd prompt in the project folder?

Anyway let me know and we will work through it together.

A.



On 18 Mar 2011, at 04:58, "karak" <notifications@codeplex.com> wrote:

From: karak

So I got the mainline synced up. TortoiseHg refuses to do it on my primary machine after many tries; doing this for branches too is going to be... prohibitive to contribution to say the least. Anyway, I tried to set up the environment with my command prompt and launch StyleCop and it failed to build. Apparently, despite having part of the process seeming to be that it verifies PowerShell can execute, actually running environment.cmd doesn't work. This is pretty silly and not good for potential contributors... rant aside, I'm looking to fix this. First step is to get rid of reliance on some unnecessary environment variables, namely ProjectRoot. Changing the projects and targets files to all use correct relative paths will fix this. Just figured to give a heads up about what I'm working on so efforts don't have to be duplicated, and to see if anyone thinks it's actually a bad idea. (Going is slow though as my time blocks are limited lately and the source control issues really aren't helping.) Maybe the ProjectRoot or other env vars are used in actually-important ways that I'm not familiar with yet. IMO we really should strive to get to a point where we just open the solution and it builds correctly. Anything else is a major deterrant towards potential new contributors.

Coordinator
Mar 18, 2011 at 8:51 AM
Also check your cmd prompt needs to be run as an administrator
Developer
Mar 18, 2011 at 8:14 PM

I can get setup, I just don't think the averate volunteer should have to jump through hoops, just to get a solution to even compile.  Pain leads to loss in interest to volunteer.

A quick test showed removing the project deps on ProjectRoot will be straight-forward.  Hopefully I'll have time this weekend to search for other uses of ProjectRoot, fix them if possible, and get the changes committed into a fork.  (I still have yet to verify that the large-unmanaged solution perf fix is still working too in mainline.)

Developer
Mar 19, 2011 at 10:29 PM

Created work item http://stylecop.codeplex.com/workitem/6830

Developer
Mar 20, 2011 at 1:39 AM

Ok so that fork now has projects/targets files which all have relative paths.  It opens and builds for me without having to run Environment.cmd, which certainly improves the workflow for those who don't want to use commandline for this stuff.

I'm partway through replacing all the batch files %PROJECTROOT% with %~dp0 style relative paths to solve the same problems.  (Self note: tackle EnvironmentRoot after this.)  The problems I'm running into are not technical, just organizational.  Having three different "tools" folders is not good.  I'm going to have to review all my replacements to figure out which ones are pointing to the right tools folders now, etc.  In fact, anyone konw what the purpose of "Project.Autofix" in it's entirety is for?  It looks redundant and out of date in cases - I'm currently under the assumption that it's going to go away entirely so I don't need the scripts in there to work...?  We have a lot of redundancy, in scripts, tools, and code, which we should be able to clean up a lot.  :)

Coordinator
Mar 20, 2011 at 7:00 AM
Great work Karak. There's a work item already open to sort out the tools folders.

Project.AutoFix is the code for the next version of stylecop that has the ability to fix errors as it finds them. So it's actually more up to date than Project folder but does lack the last 74 bug fixes I've made.
Developer
Mar 20, 2011 at 6:43 PM
andyr wrote:
Project.AutoFix is the code for the next version of stylecop that has the ability to fix errors as it finds them.

That sounds like a call for a fork?  Or maybe having build configs like Debug.AutoFix and Release.AutoFix setup with something like #if to add/alter the functionality.  (As is, hopefully Mercurial/clients are good at helping integrate changes between arbitrary folders and not just between forks...  I don't have enough experience with it to know myself.)

I take it we are just trying to hold off on said autofix features in order to get a more practical target release for 4.5 out in the near future?  After which we can merge those features into the mainline?  Sounds like a good strategy to me.

Coordinator
Mar 20, 2011 at 6:52 PM
Yep. 4.5 is mostly bug fixes and a few new rules and the first community owned release.

5.0 will have any major new features.
Coordinator
Mar 21, 2011 at 9:22 PM

Hi Karak,

I completed the merge of the tools folders just now in changeset 08981ceaf58a. Have a look at WorkItem 6684 please. There are still some dependencies on %PROJECTROOT%, %STTOOLS% and %ENLISTMENTROOT% but now there is only 1 Tools folder, 1 scripts folder etc.

Developer
Mar 29, 2011 at 8:25 PM

Ready to integrate.  The pull request is timing out too, so hopefully that either went through or isn't required.

Coordinator
Mar 29, 2011 at 8:29 PM
Edited Apr 3, 2011 at 11:01 AM
Yep. Have the request.
Hoping to get to this on Monday April 4th.
A.



On 29 Mar 2011, at 21:25, "Karak" <notifications@codeplex.com> wrote:

From: Karak

Ready to integrate. The pull request is timing out too, so hopefully that either went through or isn't required.

Oct 25, 2012 at 8:14 PM

When is the ETA for this fix?  I'm running into a lot of trouble opening the solution for the first time.  About 15 projects won't even load in VS.  I'm aware now that I have to run some ".cmd" file to set up my environment.  It doesn't feel right...

Thanks,
Dave

Oct 25, 2012 at 8:18 PM
Edited Oct 25, 2012 at 8:18 PM

I just looked at the .cmd file and it looks like it's adding a lot of environment variables.  Is it doing anything else?

More importantly, are all of these changes easily reversible?  E.g., is there an "uninstall.cmd" file somewhere?  This is very important to me because I just wanted to try and make a very quick fix and then upload my changes to the Fork, uninstall Mecurial and VisualHg, and delete the StyleCop source code.  It was supposed to be a quick one-time update.  I may have to abandon it though  :(

- Dave

Coordinator
Oct 25, 2012 at 8:38 PM
Follow the instructions in the docs section on setting up your build and you'll be fine.


~A.

On 25 Oct 2012, at 21:14, davedev <notifications@codeplex.com> wrote:

From: davedev

When is the ETA for this fix? I'm running into a lot of trouble opening the solution for the first time. About 15 projects won't even load in VS. I'm aware now that I have to run some ".cmd" file to set up my environment. It doesn't feel right...

Thanks,
Dave