Menu
▾
▴
ccnet-devel — Development List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(33) |
Jun
(44) |
Jul
(40) |
Aug
(23) |
Sep
(26) |
Oct
(41) |
Nov
(37) |
Dec
(42) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(40) |
Feb
(58) |
Mar
(81) |
Apr
(94) |
May
(77) |
Jun
(83) |
Jul
(55) |
Aug
(118) |
Sep
(51) |
Oct
(193) |
Nov
(77) |
Dec
(17) |
| 2005 |
Jan
(56) |
Feb
(87) |
Mar
(83) |
Apr
(155) |
May
(115) |
Jun
(157) |
Jul
(90) |
Aug
(87) |
Sep
(145) |
Oct
(56) |
Nov
(105) |
Dec
(88) |
| 2006 |
Jan
(56) |
Feb
(93) |
Mar
(30) |
Apr
(46) |
May
(46) |
Jun
(16) |
Jul
(33) |
Aug
(54) |
Sep
(47) |
Oct
(21) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
|
2
(2) |
3
(1) |
4
(10) |
5
(3) |
6
(8) |
7
|
|
8
(1) |
9
(6) |
10
|
11
|
12
(2) |
13
|
14
|
|
15
|
16
(2) |
17
|
18
|
19
|
20
|
21
|
|
22
|
23
(3) |
24
(5) |
25
(1) |
26
|
27
|
28
|
|
29
|
30
|
|
|
|
|
|
|
From: Mike R. <mi...@th...> - 2003-06-25 02:27:29
|
Michael L Royle wrote: > Here is my issue. CC-J is often criticized for being difficult to > install and setup (no argument from me). However, if we our target > audience for CC-.Net are Microsoft developers who are used to > installing using MSI's then we may have the same criticisms leveled at > us. Personally, I don't really care, but I thought I should at least > bring it up. Definitely worth bringing it up. The only automation the current MSI does is to setup the V-Dir and create Start Menu items. The thing is though you still need to know (really) where the install directory is to use CCNet at the moment, so I don't think this buys us that much. When we have a fancy GUI configuror, an MSI to handle multiple instances on one machine (or some other kind of multi-project support), and alternative logging schemes then I think we'd be mature enough so that an MSI wrapped app would definitely be the way to go. In terms of usability though (beyond install), I'm hoping that with 1.0 we solve the problem as much as possible by restricting all (necessary) configuration to the builder config (and a bootstrapper build file) and give good documentation. My biggest fear with usability right now is that if you don't get the config file right you still get rather ambiguous error messages. Owen / Mike 2 - did the config file schema stuff get anywhere? Mike |
|
From: Michael L R. <ML...@th...> - 2003-06-24 22:41:38
|
Here is my issue. CC-J is often criticized for being difficult to install and setup (no argument from me). However, if we our target audience for CC-.Net are Microsoft developers who are used to installing using MSI's then we may have the same criticisms leveled at us. Personally, I don't really care, but I thought I should at least bring it up. Mike Mike Roberts <mi...@th...> Sent by: ccn...@li... 06/24/2003 11:18 PM To: ccn...@li... cc: Subject: Re: [Ccnet-devel] Re: Zip File Distribution? Michael L Royle wrote: > What's the issue with creating MSI's from the build? You can create MSI's inside VS, and maybe using devenv from the command line (I'm not sure). Or you can use the <msi> task in nant-contrib which is completely separate to having an installer project in your VS solution. I don't like option (a) since I don't think we should rely on Visual Studio, and option (b) is something I haven't tried. If someone wants to try out the <msi> task that would be cool though, but I think we should still produce zip files aswell to allow for xcopy-style deployment on servers with multiple CC instances. Mike ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: Mike R. <mi...@th...> - 2003-06-24 22:18:45
|
Michael L Royle wrote: > What's the issue with creating MSI's from the build? You can create MSI's inside VS, and maybe using devenv from the command line (I'm not sure). Or you can use the <msi> task in nant-contrib which is completely separate to having an installer project in your VS solution. I don't like option (a) since I don't think we should rely on Visual Studio, and option (b) is something I haven't tried. If someone wants to try out the <msi> task that would be cool though, but I think we should still produce zip files aswell to allow for xcopy-style deployment on servers with multiple CC instances. Mike |
|
From: Michael L R. <ML...@th...> - 2003-06-24 22:01:48
|
What's the issue with creating MSI's from the build?
Mike
Mike Roberts <mi...@th...>
Sent by: ccn...@li...
06/24/2003 03:07 PM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] Re: Zip File Distribution?
Jason C Yip wrote:
>Why not do both?
>
>
Good point. :) In the short term, we're all strapped for time, so I only
wanted to suggest supporting one. Also, I don't want to continue to do
MSI drop's that aren't part of the rest of the build procedure since
that feels broken to me. So I'll change my proposal to 'Lets use zips
for binary distros until we can create MSI's in the build script'.
Thanks!
Mike
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: Mike R. <mi...@th...> - 2003-06-24 14:07:13
|
Jason C Yip wrote: >Why not do both? > > Good point. :) In the short term, we're all strapped for time, so I only wanted to suggest supporting one. Also, I don't want to continue to do MSI drop's that aren't part of the rest of the build procedure since that feels broken to me. So I'll change my proposal to 'Lets use zips for binary distros until we can create MSI's in the build script'. Thanks! Mike |
|
From: Jason C Y. <jc...@th...> - 2003-06-24 12:46:21
|
Finally got around to subscribing to this list... Why not do both? Jason Yip Software Developer, ThoughtWorks, Inc http://www.thoughtworks.com (mobile) 0418 873 729 "If you are going through hell, keep going." (Winston Churchill) |---------+-----------------------------------------> | | ccn...@li...| | | ceforge.net | | | Sent by: | | | ccn...@li...| | | forge.net | | | | | | | | | 06/24/2003 01:02 PM | | | Please respond to ccnet-devel | | | | |---------+-----------------------------------------> >-----------------------------------------------------------------------------------------------------------| | | | To: ccn...@li... | | cc: | | Subject: Ccnet-devel digest, Vol 1 #19 - 3 msgs | >-----------------------------------------------------------------------------------------------------------| Message: 3 Date: Mon, 23 Jun 2003 16:40:32 -0400 From: Mike Roberts <mi...@th...> To: ccn...@li... Subject: [Ccnet-devel] Zip File Distribution? Hi, I was talking to Mike Two over the weekend, and we discussed something I've been thinking of for a while which is to move from MSI's to zip files for our binary distributions. Why? - Much easier to setup zip file creation in our build script, so we can generate release and integration distributables much more often - Better fits the situation when you want to - check CCNet into your own source control - have multiple instances on a machine Things we lose are: - Automated virtual directory setup for web site (which is a 5 second job to do manually, and only gets done once per CC instance) - Slightly harder for newbies. Maybe. - Less flashy My proposal is that until we can get more from using an MSI that we switch to zip file distros. Does anyone have any comment? If not, I''ll add this for the next release. Mike --__--__-- _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel End of Ccnet-devel Digest |
|
From: Mike R. <mi...@th...> - 2003-06-23 20:40:40
|
Hi, I was talking to Mike Two over the weekend, and we discussed something I've been thinking of for a while which is to move from MSI's to zip files for our binary distributions. Why? - Much easier to setup zip file creation in our build script, so we can generate release and integration distributables much more often - Better fits the situation when you want to - check CCNet into your own source control - have multiple instances on a machine Things we lose are: - Automated virtual directory setup for web site (which is a 5 second job to do manually, and only gets done once per CC instance) - Slightly harder for newbies. Maybe. - Less flashy My proposal is that until we can get more from using an MSI that we switch to zip file distros. Does anyone have any comment? If not, I''ll add this for the next release. Mike |
|
From: Mike R. <mi...@th...> - 2003-06-23 19:54:33
|
Hi Dan, SF anonymous CVS has been pretty flakey for the past couple of weeks for a lot of projects. You might want to try using http://cvsgrab.sourceforge.net/ to get the cached version from SF's ViewCVS (I tried it last week for a couple of projects and it seems to work quite nicely). If necessary I'll put a zip file of latest CVS on the website. Mike Daniel E Mercier wrote: > > I have been unable to do a checkout of the code using anonymous access > or my sourceforge regular login. > IS there currently something wrong with the repository as I can > checkout other Sourceforge projects. > Dan |
|
From: Daniel E M. <DMe...@th...> - 2003-06-23 19:33:11
|
I have been unable to do a checkout of the code using anonymous access or my sourceforge regular login. IS there currently something wrong with the repository as I can checkout other Sourceforge projects. Dan |
|
From: Mike R. <mi...@th...> - 2003-06-16 19:42:45
|
The fix to this is at : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconenablingjit-attachdebugging.asp (thanks to Paul Gale for finding this) This registry change should be recommended for all CCNet machines - I'll add it to the docs just as soon as i find a convenient round tuit. Mike MRo...@th... wrote: > > The J-out-of-T debugging issue is still relevant on machines without > VS as I hit this very thing this week on a build box without it. I > haven't got around to finding the switch to turn it off yet, but at a > quick glance, I don't think its anything you can put in an > application's .config file. > > Another problem I had with this situation is that my ccnet.state file > was left in corrupt condition, and CCNet would not start without me > manually editting the file (deleting the contents of the <output> tag > worked for me) - this is bug and needs to be fixed (its on my list, > but if anyone else fancies looking at it, go ahead! :) ) > > Mike > > > > > *mc...@th...* > Sent by: ccn...@li... > > 06/05/2003 09:49 AM > > > To: ccn...@li... > cc: > Subject: RE: [Ccnet-devel] Re: shipping nant with ccnet > > > > > > CCnet has a build timeout feature already. I think it defaults to 30 > seconds. There is a possibility that it isn't working right or that it > has trouble with the modal dialog. If this modal dialog is the > typical, "You're stupid app through an exception! Do you want to > debug? yada yada" (Paraphrasing, in case you couldn't tell.) then > there is a way to turn that off. When it is off the exception just > gets thrown and things proceed as usual. This only happens on machines > with vs.net installed (I think, not 100% positive on that). It is > called Just In Time debugging. Although, "Just one line of code too > late" might be more apt. > > To turn off just in time debugging on a machine with vs.net installed > go into vs.net, tools menu, select options, expand the debugging > folder and select the just in time debugging option. Uncheck everything. > > I think that should be a standard setup on a build machine. > > If only the .NET runtime is installed I don't know if the same thing > happens. > > Mike Two; Putting the tWo in Thoughrks |
|
From: <MRo...@th...> - 2003-06-16 03:43:08
|
Hi, For those of you that don't know we've been 'loosely' using Jira to keep track of issues - see http://jira.truemesh.com, and look at the CruiseControl.NET project. In order to try and add visibility to this, I've setup another email list on Sourceforge called 'ccnet-jira', and have setup a subscription on Jira that will post to this list every day if there have been any changes to the CruiseControl.NET Jira issues, and include brief details on those that have. If you're interested in such things, just sign up in the normal way. I also plan to setup an email address that people can *send* email to that will automatically create a new issue in Jira. Mike |
|
From: <WEC...@th...> - 2003-06-12 16:52:11
|
>I'm afraid I'm ordaining that practicality wins over hot-dogging ( !! ),
and have made this change. Doc updated too.
Spoil sport :-D
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
--------
"Its the foolish cat that looks at the finger when it is pointing at the
food"
MRo...@th...
Sent by: To: ccn...@li...
ccn...@li... cc:
ceforge.net Subject: Re: [Ccnet-devel] buildTimeout default value
06/12/2003 09:57 AM
I'm afraid I'm ordaining that practicality wins over hot-dogging ( !! ),
and have made this change. Doc updated too.
seconds over millis - sounds like a good idea to me. We just need to be
consistent throughout the app and put up some release notes for the release
it is included in.
Mike
mc...@th...
Sent by: To:
ccn...@li... ccn...@li...
orge.net cc:
Subject: Re:
[Ccnet-devel] buildTimeout default
06/09/2003 11:51 AM value
I'm inclined to agree.
My first encounter with buildTimeout was before you could set it in the
config and it forced my build to fail everytime. I'd like to see the
default in code be infinite and the default in the ccnet.config we ship be
1 minute.
While we are on the subject of timing and such how do people feel about
switching to a more reasonable unit than milliseconds? It is the easist
thing to write code against, but I find it a bit odd to always have so many
zero's floating around. Can anyone come up with a compeling reason to have
anything less than 1 second precision? I'm in no hurry to change it just
thought it might warrant discussing.
Mike Two; Putting the tWo in Thoughrks
MRo...@th...
Sent by: To:
ccn...@li... ccn...@li...
rge.net cc:
Subject: [Ccnet-devel]
buildTimeout default value
06/08/2003 06:31 PM
Currently the 'buildTimeout' property defaults to 1 minute if not set. This
is probably a bad default since a lot of builds will be longer. I'd like to
suggest that if a default is not set, then we actually don't set a timeout
(i.e. we would call process.WaitForExit() rather than
process.WaitForExit(BuildTimeout) if a timeout is not set)
Anyone else have any opinion either way?
Mike
|
|
From: <MRo...@th...> - 2003-06-12 13:57:50
|
I'm afraid I'm ordaining that practicality wins over hot-dogging ( !! ),
and have made this change. Doc updated too.
seconds over millis - sounds like a good idea to me. We just need to be
consistent throughout the app and put up some release notes for the
release it is included in.
Mike
mc...@th...
Sent by: ccn...@li...
06/09/2003 11:51 AM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] buildTimeout default value
I'm inclined to agree.
My first encounter with buildTimeout was before you could set it in the
config and it forced my build to fail everytime. I'd like to see the
default in code be infinite and the default in the ccnet.config we ship be
1 minute.
While we are on the subject of timing and such how do people feel about
switching to a more reasonable unit than milliseconds? It is the easist
thing to write code against, but I find it a bit odd to always have so
many zero's floating around. Can anyone come up with a compeling reason to
have anything less than 1 second precision? I'm in no hurry to change it
just thought it might warrant discussing.
Mike Two; Putting the tWo in Thoughrks
MRo...@th...
Sent by: ccn...@li...
06/08/2003 06:31 PM
To: ccn...@li...
cc:
Subject: [Ccnet-devel] buildTimeout default value
Currently the 'buildTimeout' property defaults to 1 minute if not set.
This is probably a bad default since a lot of builds will be longer. I'd
like to suggest that if a default is not set, then we actually don't set a
timeout (i.e. we would call process.WaitForExit() rather than
process.WaitForExit(BuildTimeout) if a timeout is not set)
Anyone else have any opinion either way?
Mike
|
|
From: <mc...@th...> - 2003-06-09 16:19:55
|
I'll buy that.
Mike Two; Putting the tWo in Thoughrks
William E Caputo@THOUGHTWORKS
06/09/2003 11:17 AM
To: mc...@th...@THOUGHTWORKS_COM
cc: ccn...@li..., ccn...@li...
Subject: Re: [Ccnet-devel] buildTimeout default value
>Can anyone come up with a compeling reason to have anything less than 1
second precision?
So you can hot dog stand someone's build script? :-)
mc...@th...
Sent by: ccn...@li...
06/09/2003 11:51 AM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] buildTimeout default value
I'm inclined to agree.
My first encounter with buildTimeout was before you could set it in the
config and it forced my build to fail everytime. I'd like to see the
default in code be infinite and the default in the ccnet.config we ship be
1 minute.
While we are on the subject of timing and such how do people feel about
switching to a more reasonable unit than milliseconds? It is the easist
thing to write code against, but I find it a bit odd to always have so
many zero's floating around. Can anyone come up with a compeling reason to
have anything less than 1 second precision? I'm in no hurry to change it
just thought it might warrant discussing.
Mike Two; Putting the tWo in Thoughrks
MRo...@th...
Sent by: ccn...@li...
06/08/2003 06:31 PM
To: ccn...@li...
cc:
Subject: [Ccnet-devel] buildTimeout default value
Currently the 'buildTimeout' property defaults to 1 minute if not set.
This is probably a bad default since a lot of builds will be longer. I'd
like to suggest that if a default is not set, then we actually don't set a
timeout (i.e. we would call process.WaitForExit() rather than
process.WaitForExit(BuildTimeout) if a timeout is not set)
Anyone else have any opinion either way?
Mike
|
|
From: <WEC...@th...> - 2003-06-09 16:17:51
|
>Can anyone come up with a compeling reason to have anything less than 1
second precision?
So you can hot dog stand someone's build script? :-)
mc...@th...
Sent by: To: ccn...@li...
ccn...@li... cc:
ceforge.net Subject: Re: [Ccnet-devel] buildTimeout default value
06/09/2003 11:51 AM
I'm inclined to agree.
My first encounter with buildTimeout was before you could set it in the
config and it forced my build to fail everytime. I'd like to see the
default in code be infinite and the default in the ccnet.config we ship be
1 minute.
While we are on the subject of timing and such how do people feel about
switching to a more reasonable unit than milliseconds? It is the easist
thing to write code against, but I find it a bit odd to always have so many
zero's floating around. Can anyone come up with a compeling reason to have
anything less than 1 second precision? I'm in no hurry to change it just
thought it might warrant discussing.
Mike Two; Putting the tWo in Thoughrks
MRo...@th...
Sent by: To:
ccn...@li... ccn...@li...
rge.net cc:
Subject: [Ccnet-devel]
buildTimeout default value
06/08/2003 06:31 PM
Currently the 'buildTimeout' property defaults to 1 minute if not set. This
is probably a bad default since a lot of builds will be longer. I'd like to
suggest that if a default is not set, then we actually don't set a timeout
(i.e. we would call process.WaitForExit() rather than
process.WaitForExit(BuildTimeout) if a timeout is not set)
Anyone else have any opinion either way?
Mike
|
|
From: <mc...@th...> - 2003-06-09 15:51:37
|
I'm inclined to agree.
My first encounter with buildTimeout was before you could set it in the
config and it forced my build to fail everytime. I'd like to see the
default in code be infinite and the default in the ccnet.config we ship be
1 minute.
While we are on the subject of timing and such how do people feel about
switching to a more reasonable unit than milliseconds? It is the easist
thing to write code against, but I find it a bit odd to always have so
many zero's floating around. Can anyone come up with a compeling reason to
have anything less than 1 second precision? I'm in no hurry to change it
just thought it might warrant discussing.
Mike Two; Putting the tWo in Thoughrks
MRo...@th...
Sent by: ccn...@li...
06/08/2003 06:31 PM
To: ccn...@li...
cc:
Subject: [Ccnet-devel] buildTimeout default value
Currently the 'buildTimeout' property defaults to 1 minute if not set.
This is probably a bad default since a lot of builds will be longer. I'd
like to suggest that if a default is not set, then we actually don't set a
timeout (i.e. we would call process.WaitForExit() rather than
process.WaitForExit(BuildTimeout) if a timeout is not set)
Anyone else have any opinion either way?
Mike
|
|
From: <JA...@th...> - 2003-06-09 15:21:45
|
Yes, we had exactly the same problem. Originally we made pretty much the same fix that Dave outlines on Jira, but it's far from ideal because it would probably break every source control tool other than Perforce. The fundamental issue seems to be that Perforce works differently to (eg) CVS, and should be treated differently by CC. I'm not the best best person to explain why, but it had something to do with sync commands, changelists, and Mercury being aligned with Pluto. Mike Royle or Brent would know more. Jim |---------+---------------------------------------> | | MRo...@th... | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 09/06/2003 01:57 | | | | |---------+---------------------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: ccn...@li... | | cc: pe...@co... | | Subject: [Ccnet-devel] Perforce modification set problem | >------------------------------------------------------------------------------------------------------------------------------| I haven't looked at the Jira page for a while before today, but just saw http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-40 which describes a problem with the Perforce code not picking up modification sets properly (don't know who wrote that shoddy p4.cs code *cough* *cough* :) ) I know you London folks were coming across a similar problem - did you come up with a fix? Even if you didn't is there any chance one of you could look at this since I don't have a real perforce project to hit at the moment? Thanks, Mike |
|
From: <MRo...@th...> - 2003-06-09 15:08:45
|
Hi all, I've updated the CCNet Website at http://ccnet.thoughtworks.com/ (http://continuousintegration.org now also points to the same place) Major differences are: - The documentation is now a copy of that in the main project (the website module in CVS now has a build script that combines the main website and the doc folder - I'll be adding another target that automatically uploads the site to the webserver) (NB - right now the website module of CVS is not up to date - my connection failed last night while I was trying to upload so CVS has gone screwy - I need to figure out how to log in to the server and sort it out) - I changed the home page quite a lot, and added a 'project details' page - if anyone has any problems about this please reply. (For example, currently I've only mentioned Owen, Mike and myself as admin's on the web page - Bill & Jeremy if you would like to be on the list too, please let me know) I also updated some of the documentation, primarily updates to the ccnet.config page. Still to do on docs is a general summary of CI, automated CI and CCNet; a better version of the installer page; a better description of how to use Nant; more tips and tricks (e.g. 'When things go bad'). I plan on doing this over the next couple of weeks. Mike -- Mike Roberts Y! IM: mike_b_roberts US Cell : +1 312 953 8297 UK Mobile : +44 (0) 7900 243057 |
|
From: <MRo...@th...> - 2003-06-09 00:57:27
|
I haven't looked at the Jira page for a while before today, but just saw http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-40 which describes a problem with the Perforce code not picking up modification sets properly (don't know who wrote that shoddy p4.cs code *cough* *cough* :) ) I know you London folks were coming across a similar problem - did you come up with a fix? Even if you didn't is there any chance one of you could look at this since I don't have a real perforce project to hit at the moment? Thanks, Mike |
|
From: <MRo...@th...> - 2003-06-08 23:31:39
|
Currently the 'buildTimeout' property defaults to 1 minute if not set. This is probably a bad default since a lot of builds will be longer. I'd like to suggest that if a default is not set, then we actually don't set a timeout (i.e. we would call process.WaitForExit() rather than process.WaitForExit(BuildTimeout) if a timeout is not set) Anyone else have any opinion either way? Mike |
|
From: <mc...@th...> - 2003-06-06 15:44:58
|
You still can run a custom version even if it is in the gac. I do it with
nunit all the time. My custom version has a different version number so
when I reference it in another app even though the gac is checked first it
still keeps looking for my custom version.
So if I don't have a custom version I don't need to have multiple copies,
but if I do have a custom version I can still use it. Also I don't care
about the installer putting it in the gac. I'm fine with a zip file but it
would be nice if it contained signed assemblies.
One of the key features we had in nunit was the ability to leave
the nunit gui up with an assembly open and still be able to recompile it
in visual studio and have nunit pick up the changes. Visual studio has a
tendency to lock dlls (okay it is more than a tendency, it seems to be an
addiction). This required the ability for us to unload the assembly. You
can't actually unload assemblies, but you can unload an AppDomain. So
nunit loads the tests in a new appdomain. When it needs to reload them it
unloads the app domain and makes a new one. Since the gui is running in
one app domain and the tests are in another there is remoting going on.
If you have used nunit you may have noticed that when you add the
using statement and type NUnit. two namespaces come up, core and
framework. If you are just writing tests you use framework. This was our
bad solution to a problem that the gac fixes for us. We had to put
NUnit.Core in the same assembly as NUnit.Framework (or so we thought)
because we have to run some of the code from core in that second app
domain. Since the second app domain is rooted where the assembly under
test (i.e. the one with the tests in it) and the code in core had to be
visible to that assembly. Since framework has to be visible too we put
them in the same place. We tried to solve it by using private bin path and
so forth but that must be a subdirectory of the code base for the app
domain. This was still early in the development cycle and we hadn't signed
the assembly yet. If we had signed it and put it in the gac we could have
kept core and framework separate (as they originally were) since anytime
.net goes assembly huniting (technically called fusion) it looks in the
gac first.
Might be a bit of an extreme example but we wanted to keep the code you
need to write tests separate from the code we use to run tests and the gac
would allow us to do that.
I'm not saying everything should be put in the gac because I think it is a
bad idea to do that, but saying nothing should is also not good. It can be
a good tool to use.
Mike Two; Putting the tWo in Thoughrks
Jeremy Stell-Smith <ste...@ya...>
Sent by: ccn...@li...
06/05/2003 09:17 PM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] Re: shipping nant with ccnet
yeah. Something in the gac becomes a prereq for every
developer, becomes an extra step in the msi, becomes
something else we have to uninstall/install, etc.
Every time we install it/change it/upgrade it, tons of
pain.
If it behaved like maven does, where you ask for
something and it will go and install it for you, then
maybe, but even then. It ties you down to things that
are released and numbered. You can't have a version
of fit or nunit that you customize for your project.
For something like the .net framework that we're
pretty much guaranteed won't change for a while, that
needs a huge install, etc - ok. Otherwise, give me
"xcopy" any day.
Jeremy
--- mc...@th... wrote:
> The GAC is designed to allow you to have two (or
> more) environments on the
> same machine. I don't think it is completely
> succesful and a bit of a pain
> in the ass. The idea is that if you sign an assembly
> and give it a full
> version number you can have multiple versions of the
> assembly in the gac
> at the same time. Then in your app the metadata in
> the assembly is
> supposed to say what version you actually compiled
> against. That isn't
> always perfect so you can specify dependent
> assemblies in the config file
> for your app. You can also say things like "may app
> depends on any version
> before version 3.9" and crap like that.
> When it is done right I actually prefer this to
> having six copies of the
> junit 3.7 jar. The problem is it is rarely done
> right and it forces you
> into signing assemblies.
>
> Mike Two; Putting the tWo in Thoughrks
>
>
>
>
> Mike Roberts <mi...@th...>
> Sent by: ccn...@li...
> 06/04/2003 09:33 AM
>
>
> To: ccn...@li...
> cc:
> Subject: Re: [Ccnet-devel] Re:
> shipping nant with ccnet
>
>
> Bill said...
>
> >3) Wanting the dev tools out of the testing
> environment is looking at the
> >situation backwards. What we really want is to test
> in an environment
> that
> >matches production. If that environment does not
> include the dev tools,
> >then we want to test in an environment that doesn't
> include them either.
> >Adding fewer dev tools isn't the best answer,
> having two environments (as
> >Erik suggests) is a better answer. Note that
> running tests on the build
> >machine is still better than not running them at
> all, so even if we can't
> >have two environments I would argue that its better
> to make the box like
> a
> >dev machine, rather than limit build confidence.
> >
> >
> The key to this thread is definitely the mixed roles
> in CI of build and
> test. I agree that having separate environments for
> these two roles is
> clearly the safest (one with the dev tools, one
> without, respectively),
> and this could easily be implemented when we add the
> CCAnywhere
> distribution concepts to CC.Net.
>
> However, if you don't have the availability of 2
> separated environments,
> I would disagree with deferring
> 'production-environment' testing to a
> post-CI environment. Why? Because I think debugging
> on a build machine
> is much less of a smell than debugging on (say) a QA
> machine where more
> stake-holders are involved with what is going on.
>
> Thinking about it, this is one of the reasons I
> don't like the GAC and
> its the same reason that we steer away from using
> global environment
> variables (for example) - it should be perfectly
> possible to have 2
> independent environments on one machine. This was
> always the case with
> J2EE where you could have 2 totally separate
> instances of your App
> Server installed that had no shared configuration or
> libraries.
>
> Erik said...
>
> > I diagree because I think it is "unfair" to the
> developer. If you did
> everything right on your dev box then it should
> automatically work on the
> integration box. If that box has a different
> environment, you force the
> developer to log into this machine to diagnose the
> problem. Isn't that
> wrong? Shouldn't they be able to solve the problem
> on the dev box and use
> the integration box for verification?
>
> There are plenty of situations where as a developer
> you can have a good
> build (i.e. you did everything 'right') on your own
> machine that breaks
> at CI time - files not checked in, introduction of
> environmental
> requirements that are not implemented on the build
> machine, etc.
> 'Forcing the developer to log in' makes this sound
> like a huge deal -
> remember that before automated CI (i.e.
> CruiseControl), CI was a manual
> task performed by the checking-in developer on a
> separate machine, but
> within the team environment. CC automates this, but
> we should still
> consider the integration environment part of the
> development process,
> and developers should be happy and able to debug on
> here as necessary.
> It is the buildmaster's job to enable them to do
> this as painlessly as
> possible (but fundamentally if a developer breaks
> the build it is there
> responsiblity to fix it, not the buildmaster's)
>
> This is all tending towards the religious, so I'll
> stop now. :)
>
> Mike
>
>
>
>
-------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of
> TotalView, The best
> thread debugger on the planet. Designed with thread
> debugging features
> you've never dreamed of, try TotalView 6 free at
> www.etnus.com.
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
>
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>
>
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: <mc...@th...> - 2003-06-06 15:37:59
|
I wasn't trying to say everyone must use the gac for all of their assemblies. I was trying to say that for tools and frameworks I would rather have signed assemblies so I can put them in the gac if I want. The problems I've encountered come more from the java world than ..NET. Looking at most of our java development boxes and seeing 5 copies of junit 3.7 jar and 3 of weblogic.jar and 34 copies of xalan.jar (none of them being the same). In .NET I keep seeing multiple copies of nunit-framework.dll (and usually all the other dll's even though they are never referenced). Despite the usually state of my desk I don't like clutter. It has lead to problems in the past. When I first joined CAT ther were two weblogic jars in their source tree, god help you if you used the wrong one. I am of the oppinion that you should always start out with only one copy of a tool or framework and then making copies only when necessary. I know this means you can't quite get to the point of setting up a new machine just by checking out from source control and hitting build. I don't think that will ever work in the .net world anyway. For framework like tools (e.g. nunit or fit) I'd rather have signed assemblies. I don't care if they are in the gac or not, but they should be signed (fit does not sign fit.dll and it causes issues). For things like cc.net which runs on its own and you are less likely to build an app that refers to its dlls I don't think it matters if they are signed or not. Mike Two; Putting the tWo in Thoughrks PG...@th... Sent by: ccn...@li... 06/06/2003 01:00 AM To: ccn...@li... cc: Subject: Re: [Ccnet-devel] Re: shipping nant with ccnet >The GAC is designed to allow you to have two (or more) environments on the same machine True but you can have N versions of an app on a machine without ever using the GAC. The GAC is just one way to do it. You always have to sign assemblies if you want versioning whether it is through the GAC or not. The config file entries are the same. Just remember that the GAC is consulted first when assembly resolution is being performed. The difficulties of versioning does not have anything to do with the GAC per se.The GAC is just a location for deploying assemblies for machine wide use. Also the GAC can only be administered by administrators, which may be another reason for wanting to use it, say, to prevent regular users that don't have administrative priviledges, from adding or deleting assemblies. That having been said I prefer to keep as much local as possible and not in the GAC. It simplifies deployment and unless I want other apps to use my assemblies then I see no reason to use it. There are some circumstances when an assembly has to be GAC'd, i.e., when you're writing a system service, but those cases are rare. Mandating that everyone that wants versioning has to use the GAC sounds, in some sense, like the registry all over again. Can you give a more concrete example as I'm not clear why you think it's a problem? Perhaps you've encountered scenarios that I'm not aware of. Thanks, Paul Gale mc...@th... Sent by: ccn...@li... 06/04/2003 10:41 AM To: ccn...@li... cc: Subject: Re: [Ccnet-devel] Re: shipping nant with ccnet The GAC is designed to allow you to have two (or more) environments on the same machine. I don't think it is completely succesful and a bit of a pain in the ass. The idea is that if you sign an assembly and give it a full version number you can have multiple versions of the assembly in the gac at the same time. Then in your app the metadata in the assembly is supposed to say what version you actually compiled against. That isn't always perfect so you can specify dependent assemblies in the config file for your app. You can also say things like "may app depends on any version before version 3.9" and crap like that. When it is done right I actually prefer this to having six copies of the junit 3.7 jar. The problem is it is rarely done right and it forces you into signing assemblies. Mike Two; Putting the tWo in Thoughrks Mike Roberts <mi...@th...> Sent by: ccn...@li... 06/04/2003 09:33 AM To: ccn...@li... cc: Subject: Re: [Ccnet-devel] Re: shipping nant with ccnet Bill said... >3) Wanting the dev tools out of the testing environment is looking at the >situation backwards. What we really want is to test in an environment that >matches production. If that environment does not include the dev tools, >then we want to test in an environment that doesn't include them either. >Adding fewer dev tools isn't the best answer, having two environments (as >Erik suggests) is a better answer. Note that running tests on the build >machine is still better than not running them at all, so even if we can't >have two environments I would argue that its better to make the box like a >dev machine, rather than limit build confidence. > > The key to this thread is definitely the mixed roles in CI of build and test. I agree that having separate environments for these two roles is clearly the safest (one with the dev tools, one without, respectively), and this could easily be implemented when we add the CCAnywhere distribution concepts to CC.Net. However, if you don't have the availability of 2 separated environments, I would disagree with deferring 'production-environment' testing to a post-CI environment. Why? Because I think debugging on a build machine is much less of a smell than debugging on (say) a QA machine where more stake-holders are involved with what is going on. Thinking about it, this is one of the reasons I don't like the GAC and its the same reason that we steer away from using global environment variables (for example) - it should be perfectly possible to have 2 independent environments on one machine. This was always the case with J2EE where you could have 2 totally separate instances of your App Server installed that had no shared configuration or libraries. Erik said... > I diagree because I think it is "unfair" to the developer. If you did everything right on your dev box then it should automatically work on the integration box. If that box has a different environment, you force the developer to log into this machine to diagnose the problem. Isn't that wrong? Shouldn't they be able to solve the problem on the dev box and use the integration box for verification? There are plenty of situations where as a developer you can have a good build (i.e. you did everything 'right') on your own machine that breaks at CI time - files not checked in, introduction of environmental requirements that are not implemented on the build machine, etc. 'Forcing the developer to log in' makes this sound like a huge deal - remember that before automated CI (i.e. CruiseControl), CI was a manual task performed by the checking-in developer on a separate machine, but within the team environment. CC automates this, but we should still consider the integration environment part of the development process, and developers should be happy and able to debug on here as necessary. It is the buildmaster's job to enable them to do this as painlessly as possible (but fundamentally if a developer breaks the build it is there responsiblity to fix it, not the buildmaster's) This is all tending towards the religious, so I'll stop now. :) Mike ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: <MRo...@th...> - 2003-06-06 09:21:09
|
The J-out-of-T debugging issue is still relevant on machines without VS as
I hit this very thing this week on a build box without it. I haven't got
around to finding the switch to turn it off yet, but at a quick glance, I
don't think its anything you can put in an application's .config file.
Another problem I had with this situation is that my ccnet.state file was
left in corrupt condition, and CCNet would not start without me manually
editting the file (deleting the contents of the <output> tag worked for
me) - this is bug and needs to be fixed (its on my list, but if anyone
else fancies looking at it, go ahead! :) )
Mike
mc...@th...
Sent by: ccn...@li...
06/05/2003 09:49 AM
To: ccn...@li...
cc:
Subject: RE: [Ccnet-devel] Re: shipping nant with ccnet
CCnet has a build timeout feature already. I think it defaults to 30
seconds. There is a possibility that it isn't working right or that it has
trouble with the modal dialog. If this modal dialog is the typical,
"You're stupid app through an exception! Do you want to debug? yada yada"
(Paraphrasing, in case you couldn't tell.) then there is a way to turn
that off. When it is off the exception just gets thrown and things proceed
as usual. This only happens on machines with vs.net installed (I think,
not 100% positive on that). It is called Just In Time debugging. Although,
"Just one line of code too late" might be more apt.
To turn off just in time debugging on a machine with vs.net installed go
into vs.net, tools menu, select options, expand the debugging folder and
select the just in time debugging option. Uncheck everything.
I think that should be a standard setup on a build machine.
If only the .NET runtime is installed I don't know if the same thing
happens.
Mike Two; Putting the tWo in Thoughrks
|
|
From: <PG...@th...> - 2003-06-06 06:01:04
|
>The GAC is designed to allow you to have two (or more) environments on
the same machine
True but you can have N versions of an app on a machine without ever using
the GAC. The GAC is just one way to do it.
You always have to sign assemblies if you want versioning whether it is
through the GAC or not. The config file entries are the same. Just
remember that the GAC is consulted first when assembly resolution is being
performed.
The difficulties of versioning does not have anything to do with the GAC
per se.The GAC is just a location for deploying assemblies for machine
wide use. Also the GAC can only be administered by administrators, which
may be another reason for wanting to use it, say, to prevent regular users
that don't have administrative priviledges, from adding or deleting
assemblies.
That having been said I prefer to keep as much local as possible and not
in the GAC. It simplifies deployment and unless I want other apps to use
my assemblies then I see no reason to use it. There are some circumstances
when an assembly has to be GAC'd, i.e., when you're writing a system
service, but those cases are rare. Mandating that everyone that wants
versioning has to use the GAC sounds, in some sense, like the registry all
over again.
Can you give a more concrete example as I'm not clear why you think it's a
problem? Perhaps you've encountered scenarios that I'm not aware of.
Thanks,
Paul Gale
mc...@th...
Sent by: ccn...@li...
06/04/2003 10:41 AM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] Re: shipping nant with ccnet
The GAC is designed to allow you to have two (or more) environments on the
same machine. I don't think it is completely succesful and a bit of a pain
in the ass. The idea is that if you sign an assembly and give it a full
version number you can have multiple versions of the assembly in the gac
at the same time. Then in your app the metadata in the assembly is
supposed to say what version you actually compiled against. That isn't
always perfect so you can specify dependent assemblies in the config file
for your app. You can also say things like "may app depends on any version
before version 3.9" and crap like that.
When it is done right I actually prefer this to having six copies of the
junit 3.7 jar. The problem is it is rarely done right and it forces you
into signing assemblies.
Mike Two; Putting the tWo in Thoughrks
Mike Roberts <mi...@th...>
Sent by: ccn...@li...
06/04/2003 09:33 AM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] Re: shipping nant with ccnet
Bill said...
>3) Wanting the dev tools out of the testing environment is looking at the
>situation backwards. What we really want is to test in an environment
that
>matches production. If that environment does not include the dev tools,
>then we want to test in an environment that doesn't include them either.
>Adding fewer dev tools isn't the best answer, having two environments (as
>Erik suggests) is a better answer. Note that running tests on the build
>machine is still better than not running them at all, so even if we can't
>have two environments I would argue that its better to make the box like
a
>dev machine, rather than limit build confidence.
>
>
The key to this thread is definitely the mixed roles in CI of build and
test. I agree that having separate environments for these two roles is
clearly the safest (one with the dev tools, one without, respectively),
and this could easily be implemented when we add the CCAnywhere
distribution concepts to CC.Net.
However, if you don't have the availability of 2 separated environments,
I would disagree with deferring 'production-environment' testing to a
post-CI environment. Why? Because I think debugging on a build machine
is much less of a smell than debugging on (say) a QA machine where more
stake-holders are involved with what is going on.
Thinking about it, this is one of the reasons I don't like the GAC and
its the same reason that we steer away from using global environment
variables (for example) - it should be perfectly possible to have 2
independent environments on one machine. This was always the case with
J2EE where you could have 2 totally separate instances of your App
Server installed that had no shared configuration or libraries.
Erik said...
> I diagree because I think it is "unfair" to the developer. If you did
everything right on your dev box then it should automatically work on the
integration box. If that box has a different environment, you force the
developer to log into this machine to diagnose the problem. Isn't that
wrong? Shouldn't they be able to solve the problem on the dev box and use
the integration box for verification?
There are plenty of situations where as a developer you can have a good
build (i.e. you did everything 'right') on your own machine that breaks
at CI time - files not checked in, introduction of environmental
requirements that are not implemented on the build machine, etc.
'Forcing the developer to log in' makes this sound like a huge deal -
remember that before automated CI (i.e. CruiseControl), CI was a manual
task performed by the checking-in developer on a separate machine, but
within the team environment. CC automates this, but we should still
consider the integration environment part of the development process,
and developers should be happy and able to debug on here as necessary.
It is the buildmaster's job to enable them to do this as painlessly as
possible (but fundamentally if a developer breaks the build it is there
responsiblity to fix it, not the buildmaster's)
This is all tending towards the religious, so I'll stop now. :)
Mike
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: <WEC...@th...> - 2003-06-06 02:55:23
|
>I want to know if my checkin won't run on >production about as soon as I check in - if not >sooner. Agreed. I wasn't saying that I prefer to wait until some downstream time to test, but rather that I think I would rather build and run tests on the build machine -- even if the build tools are on there -- than have the build machine use a different build process than the dev machines. If running the tests this way didn't give me confidence that the build was good, then I would make every effort to have a production-like environment to test in too and if possible do it as part of the CI process. However, if the only real difference is the presence of VS on the dev machine (i.e. I could still use the same build script to do local builds) , then I think I too would probably prefer leaving VS off the build machine unless I had to put it on there. I wouldn't however want to use VS to build on the dev machine, and then some other build script on the build machine, that would make me nervous. This is what NI is toying with, and I think its already getting them into trouble. BTW, I like the description Mike gives of what you guys were doing in Redmond, sounds like a good way to go. Best, Bill William E. Caputo ThoughtWorks, Inc. -------- It is my firm belief that it is a mistake to hold firm beliefs. -- Malaclypse the Younger |
1 message has been excluded from this view by a project administrator.