From: Nicklas N. <ex...@ex...> - 2004-10-17 17:29:28
|
Hi Clayton, I took the liberty making quite a few changes on my own, testing things out. I'm not used to a common bin folder in VS projects, but I'm probably biased from work. If there are supposed to be common folders I see no reason why there should be a separate one for VS. As far as I'm concerned no matter what build system used it should produce the same output to the same places unless there is a specific reason not to. It looks to me there are three build systems supported, nant, VS.NET and eclipse. Are these supposed to work on all platforms? If not, why not move the project outputs from the VS build to the normal folders and then use build events to create the bin folder and populate it? A common bin folder is important to support tools analysing the assemlies, such as fxcop and ndoc. Also it makes running the assemblies a lot easier. I also noted the test project is refering directly to all the source in the rest of the projects. I tried to remove them and add the assemblies as project references. It worked pretty well but I got hung up on console project resulting in an executable as those can't be referenced. With your new project I think that those references can be removed making maintainance a lot easier of that project file. Way to go! Also did some looking into signing the assemblies with a strong name key and got my ass busted. Turns out that the csc task has the build directory as it's current working directory while the VS build has the obj\Debug folder as cwd. Refering to the same key becomes an impossibility :( I suppose some creative copying would take care of it... Did anyone give this any thought? Signing is a need it the library is supposed to be installed in the GAC (even if we don't others might want to). Of course, they could sign them on their own. Sorry if I'm sticking my big nose into someone elses bussiness, but I'm a build engineer since years ago and it's hard to let go on my spare time hehe. /Nicke Clayton Harbour wrote: >Hey Nicklas, > >Thanks for forwarding that link, I have known about the issue for awhile >but had not read on possible work arounds. Based on this information >and your suggestion I have updated the vs.net solution and projects. I >used the console project to "copy" all dlls' to the output directory >just by setting the copy local attribute. I am not sure if we need to >copy all of these to the bin directory. Building with both NAnt and >vs.net might mean some confusion between the two but I don't think that >switching back and forth between the two build mechanisms is very >common...please let me know if I am wrong :-). > > >Also, please note that I have also added a new sub-project for the >console application. This existed in the NAnt build but was not in the >vs.net solution (my bad, I just don't use the solution build...sorry). >The idea behind this is that the cvs.exe just provides a loading >mechanism for dependant libraries. I have not updated the sharpdevelop >build to mirror this...Gerald if you have time can you do this? > > >Cheers, > > >Clayton > > > >>-----Original Message----- >>From: Nicklas Norling [mailto:ex...@ex...] >>Sent: October 16, 2004 2:53 PM >>To: sha...@li... >>Subject: [Sharpcvslib-developers] VS.NET compile problems >> >> >>Hi. >> >>Using VS.NET 2003 to compile the solution seems to lock up the >>assemblies and give >>errors on SharpCvsLib main assembly. >>By the looks of it it appears to be the dreaded bug described in >>http://support.microsoft.com/default.aspx?scid=kb;en-us;313512. >> >>I was wondering if there is any interest in me "fixing" this by >>separating each projects >>output to a separate folder. This unfortunately means that the binary >>needs to be moved >>in place to the top bin folder or scripts relying on the >>current top bin >>folder needs to look >>elsewhere. The most obvious solution would be using copy as a >>post build >>event but that >>might be a platform issue as it would create a bat file with the >>commands entered into the >>event. Nant could also be made to copy the output after the compile >>(nant solution task >>supports post build events). >> >>What do you think? >>/Nicke >> >> |
From: Clayton H. <cla...@sp...> - 2004-10-17 19:40:37
|
-----Original Message----- From: Clayton Harbour=20 Sent: October 17, 2004 9:34 AM To: Nicklas Norling Cc: Nant-Developers (E-Mail) Subject: [nant-dev] RE: [Sharpcvslib-developers] VS.NET compile problems Hey Nicklas, Thanks for forwarding that link, I have known about the issue for awhile but had not read on possible work arounds. Based on this information and your suggestion I have updated the vs.net solution and projects. I used the console project to "copy" all dlls' to the output directory just by setting the copy local attribute. I am not sure if we need to copy all of these to the bin directory. Building with both NAnt and vs.net might mean some confusion between the two but I don't think that switching back and forth between the two build mechanisms is very common...please let me know if I am wrong :-). Also, please note that I have also added a new sub-project for the console application. This existed in the NAnt build but was not in the vs.net solution (my bad, I just don't use the solution build...sorry). The idea behind this is that the cvs.exe just provides a loading mechanism for dependant libraries. I have not updated the sharpdevelop build to mirror this...Gerald if you have time can you do this? Cheers, Clayton > -----Original Message----- > From: Nicklas Norling [mailto:ex...@ex...] > Sent: October 16, 2004 2:53 PM > To: sha...@li... > Subject: [Sharpcvslib-developers] VS.NET compile problems >=20 >=20 > Hi. >=20 > Using VS.NET 2003 to compile the solution seems to lock up the > assemblies and give > errors on SharpCvsLib main assembly. > By the looks of it it appears to be the dreaded bug described in=20 > http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;313512. >=20 > I was wondering if there is any interest in me "fixing" this by > separating each projects > output to a separate folder. This unfortunately means that the binary=20 > needs to be moved > in place to the top bin folder or scripts relying on the=20 > current top bin=20 > folder needs to look > elsewhere. The most obvious solution would be using copy as a=20 > post build=20 > event but that > might be a platform issue as it would create a bat file with the=20 > commands entered into the > event. Nant could also be made to copy the output after the compile=20 > (nant solution task > supports post build events). >=20 > What do you think? > /Nicke >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on > ITManagersJournal Use IT products in your business? Tell us=20 > what you think of them. Give us Your Opinions, Get Free=20 > ThinkGeek Gift Certificates! Click to find out more=20 > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Sharpcvslib-developers mailing list=20 > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpcvslib-developers >=20 ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ nant-developers mailing list nan...@li... https://lists.sourceforge.net/lists/listinfo/nant-developers |
From: Clayton H. <cla...@sp...> - 2004-10-17 22:24:54
|
Hey Nicklas, Great to have some initiative on this. There are actually about 4 build systems...I am not sure they should all be checked in because as you (and others) have noted it is a little bit of a PITA to keep them all inline. It was my original idea that everyone could maintain whichever one they felt most comfortable building with but it has become somewhat of a work shuffle. > -----Original Message----- > From: Nicklas Norling [mailto:ex...@ex...]=20 > Sent: October 17, 2004 10:29 AM > To: Clayton Harbour; sha...@li... > Subject: Re: [Sharpcvslib-developers] VS.NET compile problems >=20 >=20 > Hi Clayton, >=20 > I took the liberty making quite a few changes on my own,=20 > testing things=20 > out. I'm not used to a common > bin folder in VS projects, but I'm probably biased from work.=20 > If there=20 > are supposed to be common folders > I see no reason why there should be a separate one for VS. As=20 > far as I'm=20 > concerned no matter what build > system used it should produce the same output to the same=20 > places unless=20 > there is a specific reason not to. > It looks to me there are three build systems supported, nant,=20 > VS.NET and=20 > eclipse. Are these supposed to > work on all platforms?=20 You are correct, although eclipse really just pipes out to NAnt. I used it when I was doing initial work with mono on Linux but now adays there is monodevelop which does the job quite a bit better (in my opinion). The NAnt build will work on all platforms, the sharpdevelop/ monodevelop should but no guarantees. > If not, why not move the project=20 > outputs from the=20 > VS build to the normal folders > and then use build events to create the bin folder and=20 > populate it?=20 > A common bin folder is important to support=20 > tools analysing the=20 > assemlies, such as fxcop and ndoc. Also > it makes running the assemblies a lot easier. I would be okay with hooking up some post build event in vs.net to copy these over to the common bin folder if you would like to add this. I would like to keep any automation to the NAnt build scripts so if you add anything in the vs.net build that you think might be of benefit please also add it to the NAnt scripts. In the future I would like to get the NAnt build looking at the .sln files and .csproj files but there is some work involved to get the <solution/> target working on mono. >=20 > I also noted the test project is refering directly to all the=20 > source in=20 > the rest of the projects. I tried to remove > them and add the assemblies as project references. It worked=20 > pretty well=20 > but I got hung up on console project > resulting in an executable as those can't be referenced. With=20 > your new=20 > project I think that those references > can be removed making maintainance a lot easier of that project file.=20 > Way to go! >=20 The test project included all of the source from existing projects because there was some discussion awhile back about internal methods and testing such methods. The inclusion of all source files was the resolution, but it might not be the best solution. I think we still need to test internal methods, but there might be a better way...so we might have to hash out the details on this one and it might work out being a mesh of one test project for internal methods and one for public API. > Also did some looking into signing the assemblies with a=20 > strong name key=20 > and got my ass busted. > Turns out that the csc task has the build directory as it's current=20 > working directory while the VS build has > the obj\Debug folder as cwd. Refering to the same key becomes an=20 > impossibility :( I suppose some creative > copying would take care of it... Did anyone give this any thought?=20 > Signing is a need it the library is supposed > to be installed in the GAC (even if we don't others might=20 > want to). Of=20 > course, they could sign them on their own. >=20 I would be happy to just include this in the NAnt build unless there are objections, and only if needed. The GAC is a useful tool however I don't think we have a strong need for it right now. Again I am open to suggestions on this but I would be more in favor of giving an end user the ability to do this easily on their own rather than making it a common practice in our build. > Sorry if I'm sticking my big nose into someone elses=20 > bussiness, but I'm=20 > a build engineer since years ago and > it's hard to let go on my spare time hehe. >=20 No worries, and don't be sorry. If you have any more suggestions please feel free to fire away. If I am not sure of the benefit I will say so :-) and we can work it out from there. I am finding as I grow older that pride is less important than having something work right :-). Cheers, Clayton >=20 > Clayton Harbour wrote: >=20 > >Hey Nicklas, > > > >Thanks for forwarding that link, I have known about the issue for=20 > >awhile but had not read on possible work arounds. Based on this=20 > >information and your suggestion I have updated the vs.net=20 > solution and=20 > >projects. I used the console project to "copy" all dlls' to=20 > the output=20 > >directory just by setting the copy local attribute. I am=20 > not sure if=20 > >we need to copy all of these to the bin directory. Building=20 > with both=20 > >NAnt and vs.net might mean some confusion between the two=20 > but I don't=20 > >think that switching back and forth between the two build=20 > mechanisms is=20 > >very common...please let me know if I am wrong :-). > > > > > >Also, please note that I have also added a new sub-project for the=20 > >console application. This existed in the NAnt build but was=20 > not in the=20 > >vs.net solution (my bad, I just don't use the solution=20 > build...sorry).=20 > >The idea behind this is that the cvs.exe just provides a loading=20 > >mechanism for dependant libraries. I have not updated the=20 > sharpdevelop=20 > >build to mirror this...Gerald if you have time can you do this? > > > > > >Cheers, > > > > > >Clayton > > > > =20 > > > >>-----Original Message----- > >>From: Nicklas Norling [mailto:ex...@ex...] > >>Sent: October 16, 2004 2:53 PM > >>To: sha...@li... > >>Subject: [Sharpcvslib-developers] VS.NET compile problems > >> > >> > >>Hi. > >> > >>Using VS.NET 2003 to compile the solution seems to lock up the > >>assemblies and give > >>errors on SharpCvsLib main assembly. > >>By the looks of it it appears to be the dreaded bug described in=20 > >>http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;313512. > >> > >>I was wondering if there is any interest in me "fixing" this by > >>separating each projects > >>output to a separate folder. This unfortunately means that=20 > the binary=20 > >>needs to be moved > >>in place to the top bin folder or scripts relying on the=20 > >>current top bin=20 > >>folder needs to look > >>elsewhere. The most obvious solution would be using copy as a=20 > >>post build=20 > >>event but that > >>might be a platform issue as it would create a bat file with the=20 > >>commands entered into the > >>event. Nant could also be made to copy the output after the compile=20 > >>(nant solution task > >>supports post build events). > >> > >>What do you think? > >>/Nicke > >> =20 > >> >=20 |
From: Nicklas N. <ex...@ex...> - 2004-10-18 16:48:13
|
Clayton Harbour wrote: >Hey Nicklas, > >Great to have some initiative on this. There are actually about 4 build >systems...I am not sure they should all be checked in because as you >(and others) have noted it is a little bit of a PITA to keep them all >inline. It was my original idea that everyone could maintain whichever >one they felt most comfortable building with but it has become somewhat >of a work shuffle. > > > I think your idea sounds great :) If all open source projects worked like that it would be a lot less hassle. >>-----Original Message----- >>From: Nicklas Norling [mailto:ex...@ex...] >>Sent: October 17, 2004 10:29 AM >>To: Clayton Harbour; sha...@li... >>Subject: Re: [Sharpcvslib-developers] VS.NET compile problems >> >> >>Hi Clayton, >> >>I took the liberty making quite a few changes on my own, >>testing things >>out. I'm not used to a common >>bin folder in VS projects, but I'm probably biased from work. >>If there >>are supposed to be common folders >>I see no reason why there should be a separate one for VS. As >>far as I'm >>concerned no matter what build >>system used it should produce the same output to the same >>places unless >>there is a specific reason not to. >>It looks to me there are three build systems supported, nant, >>VS.NET and >>eclipse. Are these supposed to >>work on all platforms? >> >> > >You are correct, although eclipse really just pipes out to NAnt. I used >it when I was doing initial work with mono on Linux but now adays there >is monodevelop which does the job quite a bit better (in my opinion). >The NAnt build will work on all platforms, the sharpdevelop/ monodevelop >should but no guarantees. > > > > Ok, so at this time Nant is *the* build system. If I'm looking for the truth it's in it's scripts. >>If not, why not move the project >>outputs from the >>VS build to the normal folders >>and then use build events to create the bin folder and >>populate it? >>A common bin folder is important to support >>tools analysing the >>assemlies, such as fxcop and ndoc. Also >>it makes running the assemblies a lot easier. >> >> > >I would be okay with hooking up some post build event in vs.net to copy >these over to the common bin folder if you would like to add this. I >would like to keep any automation to the NAnt build scripts so if you >add anything in the vs.net build that you think might be of benefit >please also add it to the NAnt scripts. In the future I would like to >get the NAnt build looking at the .sln files and .csproj files but there >is some work involved to get the <solution/> target working on mono. > > > Ok, I'll take a look at it and see if I can come up with any improvments. I can imagine there is some work in getting the solution task running on mono, especially build events as those will generate DOS command scripts (I wrote that code). If I where to call nant and have a nant task do the deployment into the bin folder it would be much more platform independant. Solution task on mono would still need to figure out how to run it though. Maybe build events won't work on mono. Ohh well, it can always be changed later on, not written in stone. >>I also noted the test project is refering directly to all the >>source in >>the rest of the projects. I tried to remove >>them and add the assemblies as project references. It worked >>pretty well >>but I got hung up on console project >>resulting in an executable as those can't be referenced. With >>your new >>project I think that those references >>can be removed making maintainance a lot easier of that project file. >>Way to go! >> >> >> > >The test project included all of the source from existing projects >because there was some discussion awhile back about internal methods and >testing such methods. The inclusion of all source files was the >resolution, but it might not be the best solution. I think we still >need to test internal methods, but there might be a better way...so we >might have to hash out the details on this one and it might work out >being a mesh of one test project for internal methods and one for public >API. > > > Testing of private metods was what I thought was the reason. But there seems to be tests only on the public interface today. I'm gonna skip this one I think :) >>Also did some looking into signing the assemblies with a >>strong name key >>and got my ass busted. >>Turns out that the csc task has the build directory as it's current >>working directory while the VS build has >>the obj\Debug folder as cwd. Refering to the same key becomes an >>impossibility :( I suppose some creative >>copying would take care of it... Did anyone give this any thought? >>Signing is a need it the library is supposed >>to be installed in the GAC (even if we don't others might >>want to). Of >>course, they could sign them on their own. >> >> >> > >I would be happy to just include this in the NAnt build unless there are >objections, and only if needed. The GAC is a useful tool however I >don't think we have a strong need for it right now. Again I am open to >suggestions on this but I would be more in favor of giving an end user >the ability to do this easily on their own rather than making it a >common practice in our build. > > > Sounds good to me, skipping this one. >>Sorry if I'm sticking my big nose into someone elses >>bussiness, but I'm >>a build engineer since years ago and >>it's hard to let go on my spare time hehe. >> >> >> > >No worries, and don't be sorry. If you have any more suggestions please >feel free to fire away. If I am not sure of the benefit I will say so >:-) and we can work it out from there. I am finding as I grow older >that pride is less important than having something work right :-). > > >Cheers, > > >Clayton > > Thanks Clayton :) Also I haven't commented on the encoding issues or :local: protocol. I think I can do the :local: if all it means is creating an interop (well, more or less...). Also the encoding, I had not realized that a change would need a new stream. I'll see if I can do some more research into it and figure out how much job it would be. I won't do anything as you said you where doing work on files. /Nicke |
From: Clayton H. <cla...@sp...> - 2004-10-19 04:10:48
|
Hi Nicklas, <snipped /> > Ok, I'll take a look at it and see if I can come up with any=20 > improvments. I can imagine there is some > work in getting the solution task running on mono, especially build=20 > events as those will generate DOS > command scripts (I wrote that code). If I where to call nant=20 > and have a=20 > nant task do the deployment > into the bin folder it would be much more platform=20 > independant. Solution=20 > task on mono would still need > to figure out how to run it though. Maybe build events won't work on=20 > mono. Ohh well, it can always be > changed later on, not written in stone. Yeah I wouldn't worry about making the vs.net targets platform independent right away. If the vs.net post build works on win32 (i.e. using a .bat file, etc.) then that is cool. Of course if it is just as easy to pipe to NAnt that is great too. =20 > Testing of private metods was what I thought was the reason.=20 > But there=20 > seems to be tests only on > the public interface today. I'm gonna skip this one I think :) Yes I think you are right...ah if there were only more time in a day :-)... =20 > Also I haven't commented on the encoding issues or :local:=20 > protocol. I=20 > think I can do the :local: if > all it means is creating an interop (well, more or less...). Also the=20 > encoding, I had not realized that > a change would need a new stream. I'll see if I can do some more=20 > research into it and figure out > how much job it would be. I won't do anything as you said you where=20 > doing work on files. I did not mean to make it sound like the :local would be trivial...it probably is not going to be when the "rubber hits the road" :-). Still it should be less complex than implementing a cvs server. Thanks for hanging off on commits Nicklas, I will try to get my changes in tonight so I can get a release to the NAnt group. After that everything should be good to go. Cheers, Clayton |
From: Clayton H. <cla...@sp...> - 2004-10-22 13:49:19
|
Hi Nicklas, >=20 > Thanks for hanging off on commits Nicklas, I will try to get=20 > my changes in tonight so I can get a release to the NAnt=20 > group. After that everything should be good to go. >=20 Feel free to commit any encoding changes you are working on. I am still making changes locally but I had to do some rework and it might be better if I integrated on this end. =20 Cheers, Clayton |