2.0 & 3.5 framework paths
Joshua Poehls
was surprised to find it wasn't in my path. I'm specifying the 3.5
framework in my script and with a bit of digging I found that
aspnet_compiler isn't in the 3.5 framework path, only in the 2.0. This
makes sense since 3.5 simply builds on 2.0.
I believe what needs to happen is Configure-BuildEnvironment needs to
be updated so that if 3.5 is picked, both the 2.0 and 3.5 paths are
added to $env:path. 3.5 first, then 2.0 (so that 3.5 tools take
precedence).
Has anyone worked on a patch for this? I went ahead and just hacked my
psake.psm1 to do this.
James Kovacs
* My current thinking is to update the version parameter to work as follows. If you pass "v3.5x64", we run under 64-bit. If you pass "v3.5x86", we run 32-bit regardless. If you pass "v3.5", we run 32-bit on 32-bit Windows and 64-bit on 64-bit Windows. The only impact that this change will have is that on 64-bit Windows, psake will start using the 64-bit tools rather than the 32-bit tools. Any concerns with this change?
James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)
--
You received this message because you are subscribed to the Google Groups "psake-dev" group.
To post to this group, send email to psak...@googlegroups.com.
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/psake-dev?hl=en.
Jorge Matos
Jorge Matos
Senior .NET Architect, MCSD.NET, MCSD Visual Studio 6.0
(440) 666-3107
matos...@hotmail.com
Blog: http://jorgelmatos.blogspot.com
--------------------------------------------------------------------------------
"Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to
move in the opposite direction."... - Albert Einstein
James Kovacs
- passing command-line parameters
- nested builds
- .NET 4.0 support
- 64-bit support
James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)
Jorge Matos
James Kovacs
- Added support for .NET 2.0 tools when running .NET 3.5 builds (e.g. aspnet_compiler)
- Support 64-bit builds
- 3.5x86 forces 32-bit
- 3.5x64 forces 64-bit
- 3.5 performs detection
- Added .NET 4.0 support
- Updated psake version to 4.00 to align with .NET 4.0 Framework support
- Re-organized examples into true examples (.\examples) and specifications (.\specs)
- psake-buildtester.ps1 now executes everything in .\specs
- Specs must end in _should_pass.ps1 or _should_fail.ps1 depending on the expected result.
Thanks,
James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)
Jorge
Thats great, I'm glad you re-organized the examples, I'm surprised I
didn't think of that!
I'll review the code this weekend and give my 2 cents.
Thanks!
On Mar 4, 12:29 am, James Kovacs <jkov...@post.harvard.edu> wrote:
> FYI - I've pushed the following changes to GitHub...
>
> - Added support for .NET 2.0 tools when running .NET 3.5 builds (e.g.
> aspnet_compiler)
> - Support 64-bit builds
> - 3.5x86 forces 32-bit
> - 3.5x64 forces 64-bit
> - 3.5 performs detection
> - Added .NET 4.0 support
> - Updated psake version to 4.00 to align with .NET 4.0 Framework support
> - Re-organized examples into true examples (.\examples) and
> specifications (.\specs)
> - psake-buildtester.ps1 now executes everything in .\specs
> - Specs must end in _should_pass.ps1 or _should_fail.ps1 depending on
> the expected result.
>
> Please take the latest bits for test drive. If everything looks good, I'll
> officially release psake 4.00 and write a corresponding blog post outlining
> the new features.
>
> Thanks,
> James
> --
> James Kovacs, B.Sc., M.Sc., MCSD, MCT
> Microsoft MVPhttp://www.jameskovacs.com
> 403-397-3177 (mobile)
>
>
>
> On Mon, Mar 1, 2010 at 2:43 PM, Jorge Matos <matos.jo...@gmail.com> wrote:
> > I vote for jumping to 4.0
>
> > On Mon, Mar 1, 2010 at 3:36 PM, James Kovacs <jkov...@post.harvard.edu>wrote:
>
> >> Good point. Should we bump it to 4.0 to align with the .NET Framework?
> >> Seems like the popular thing to do? :) I'm debating between a 2.5 and 3.0
> >> bump. Changes that I can think of (either done or pending):
>
> >> - passing command-line parameters
> >> - nested builds
> >> - .NET 4.0 support
> >> - 64-bit support
>
> >> What do you think? Deserving of a 0.5 or a full 1.0 boost?
>
> >> James
> >> --
> >> James Kovacs, B.Sc., M.Sc., MCSD, MCT
> >> Microsoft MVP
> >>http://www.jameskovacs.com
> >> jkov...@post.harvard.edu
> >> 403-397-3177 (mobile)
>
> >> On Mon, Mar 1, 2010 at 2:33 PM, Jorge Matos <matos.jo...@gmail.com>wrote:
>
> >>> I'm ok with it - should psake's version number be bumped up? I've
> >>> added a couple of significant changes recently (nested builds, -parameters)
> >>> and this will be another one.
>
> >>> On Mon, Mar 1, 2010 at 3:29 PM, James Kovacs <jkov...@post.harvard.edu
> >>> > wrote:
>
> >>>> You're correct. .NET 3.5 uses a mix of executables from the .NET 3.5
> >>>> and 2.0 directories. I also noticed while confirming the problem that we
> >>>> need to support 4.0 as well as 64-bit installs. (Right now, 64-bit installs
> >>>> use the 32-bit framework tools.)* I'm updating the
> >>>> Configure-BuildEnvironment function to handle these cases.
>
> >>>> * My current thinking is to update the version parameter to work as
> >>>> follows. If you pass "v3.5x64", we run under 64-bit. If you pass "v3.5x86",
> >>>> we run 32-bit regardless. If you pass "v3.5", we run 32-bit on 32-bit
> >>>> Windows and 64-bit on 64-bit Windows. The only impact that this change will
> >>>> have is that on 64-bit Windows, psake will start using the 64-bit tools
> >>>> rather than the 32-bit tools. Any concerns with this change?
>
> >>>> James
> >>>> --
> >>>> James Kovacs, B.Sc., M.Sc., MCSD, MCT
> >>>> Microsoft MVP
> >>>>http://www.jameskovacs.com
> >>>> jkov...@post.harvard.edu
> >>>> 403-397-3177 (mobile)
>
> >>>> On Mon, Mar 1, 2010 at 10:10 AM, Joshua Poehls <jdpoe...@gmail.com>wrote:
>
> >>>>> I tried to use aspnet_compiler in one of my build scripts today and
> >>>>> was surprised to find it wasn't in my path. I'm specifying the 3.5
> >>>>> framework in my script and with a bit of digging I found that
> >>>>> aspnet_compiler isn't in the 3.5 framework path, only in the 2.0. This
> >>>>> makes sense since 3.5 simply builds on 2.0.
>
> >>>>> I believe what needs to happen is Configure-BuildEnvironment needs to
> >>>>> be updated so that if 3.5 is picked, both the 2.0 and 3.5 paths are
> >>>>> added to $env:path. 3.5 first, then 2.0 (so that 3.5 tools take
> >>>>> precedence).
>
> >>>>> Has anyone worked on a patch for this? I went ahead and just hacked my
> >>>>> psake.psm1 to do this.
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "psake-dev" group.
> >>>>> To post to this group, send email to psak...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> psake-dev+...@googlegroups.com<psake-dev%2Bunsubscribe@googlegroups.com>
> >>>>> .
> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/psake-dev?hl=en.
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "psake-dev" group.
> >>>> To post to this group, send email to psak...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> psake-dev+...@googlegroups.com<psake-dev%2Bunsubscribe@googlegroups.com>
> >>>> .
> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/psake-dev?hl=en.
>
> >>> --
> >>> Jorge Matos
> >>> Senior .NET Architect, MCSD.NET <http://mcsd.net/>, MCSD Visual Studio
> >>> 6.0
> >>> (440) 666-3107
> >>> matos_jo...@hotmail.com
> >>> Blog:http://jorgelmatos.blogspot.com
>
> >>> --------------------------------------------------------------------------------
> >>> "Any intelligent fool can make things bigger and more complex...
> >>> It takes a touch of genius - and a lot of courage to
> >>> move in the opposite direction."... - Albert Einstein
>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "psake-dev" group.
> >>> To post to this group, send email to psak...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> psake-dev+...@googlegroups.com<psake-dev%2Bunsubscribe@googlegroups.com>
> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/psake-dev?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "psake-dev" group.
> >> To post to this group, send email to psak...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> psake-dev+...@googlegroups.com<psake-dev%2Bunsubscribe@googlegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/psake-dev?hl=en.
>
> > --
> > Jorge Matos
> > Senior .NET Architect, MCSD.NET, MCSD Visual Studio 6.0
> > (440) 666-3107
> > matos_jo...@hotmail.com
> > Blog:http://jorgelmatos.blogspot.com
>
> > --------------------------------------------------------------------------------
> > "Any intelligent fool can make things bigger and more complex...
> > It takes a touch of genius - and a lot of courage to
> > move in the opposite direction."... - Albert Einstein
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "psake-dev" group.
> > To post to this group, send email to psak...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > psake-dev+...@googlegroups.com<psake-dev%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/psake-dev?hl=en.- Hide quoted text -
>
> - Show quoted text -
Jorge
Reviewed your code changes and everything looks good, the only thing I
might add is a little more help in the invoke-psake function around
the $framework so that users will know about the "x86" and "x64"
options.
Also I'm thinking that we should move the command-line parameter
processing before the code where the properties are "." sourced - this
way I believe you can reference command line parameters from within
your properties script blocks. The downside is that you can't
override the values of your properties with the command-line
parameters, so actually I'm not sure which way to go on this. What
are your thoughts?
> > >http://groups.google.com/group/psake-dev?hl=en.-Hide quoted text -
James Kovacs
Thanks for the review. I changed the impl slightly based on feedback. The x86/x64 detection should be more robust now as I'm using [System.IntPtr]::Size as the switch. This won't be affected by bad registry entries or bad environment variables. I've also added the additional documentation as you recommended. Good catch.
As for command-line processing... That's tricky. Maybe we need to process them both before and after. Then we can use them for inputs into parameters and overrides. Thoughts?jko...@post.harvard.edu
403-397-3177 (mobile)
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.