Compiling Project Group, getting permission denied
Author |
Message |
Brian Flyn #1 / 9
|
 Compiling Project Group, getting permission denied
Hi All, When I try to compile a project group I get a permission denied when trying to compile one of the components. Here is the scenario. (For ease of understanding I'll name the component A,B, C etc...) ProjectA - Standard exe ProjectB - Dll, Binary Compatibility ProjectC - Dll, Binary Compatibility ProjectD - Dll, Binary Compatibility Project E - Dll, Binary Compatibility I have a project group created for this and all references point to the VBP and not the dll's. Here are the references. ProjectA (exe) references: ProjectB, ProjectC, ProjectD, ProjectE ProjectB has no references ProjectC has no references ProjectD references ProjectC ProjectE references ProjectB and ProjectC The order in which the files are listed in the VBG File(Which I understand is the build order) is.... Project=ProjectB Project=ProjectC Project=ProjectD Project=ProjectE StartupProject=ProjectA (exe) I get the permission denied error when the project group tries to compile ProjectE. I hope I have provided enough information. Thanks in advance, Brian Flynn
|
Sun, 11 Jul 2004 23:24:25 GMT |
|
 |
Mark Kamosk #2 / 9
|
 Compiling Project Group, getting permission denied
Hmmm... ...it could be a million different things, I say... ...however, since I once got saddled with the "Build Engineer" role on a project, I found a way out, its a long story, but here is my take... ....when I am developing and actually writing code, I am in the VB IDE with a project group open with all of the projects in it and (as you note below) I point any cross-project references to the VBP of the projects being referenced... ....I never compile a DLL in VB because VB takes control over when and where and how that DLL is registered and so on, which I don't like... ...when I need to compile 1 or all of the DLLs in the project, I use a script.... ...you can script is using WSH, VBScript, and the like, or... ....there is a great, cheap tool call VisualBuild, http://www.kinook.com , that can make it a lot easier... ....anyway, the script goes something like this... Compile ProjectA ...Check-in all files ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Unregister the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done Compile ProjectB (which has a reference to ProjectA) ...Check-in all files ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Unregister the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done Compile ProjectC (which has a reference to ProjectB) ...Check-in all files ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Unregister the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done ...and so on... ...whatever you think of it, it works... you have to maintain the script (of course) but I have used this with zero problems and was building an enterprise-level, distributed system with many DLLs in a matter of minutes... ...you have to think allot about circular references and order of dependency and that sort of thing, but once you have the script debugged, you are golden... ...By the way, here's a good, quick way to see if you have a polluted registry entries... go to VB, open >Project, >References, and start scrolling down... if you see more than 1 entry with the same name (which usually are your projects that were registered more than once on the same machine from different locations, or something similar), then you have some "bad" registry entries.... ...this, of course, is NOT a good thing, but it is quite common... ....Norton Utilities has a program called WinDoctor that can clean up some of these registry entries and (if you don't mind using an old tool) Microsoft's RegClean also is supposed to work (but I don't trust it anymore since they haven't seemed to update it in years).... ...anyway, that's my schpeel, HTH, IMHO, and all that... ...(post with more questions and if you get VisualBuild let me know and I can send you a sample script)... --Mark. Post Script: Oh yeah, one more thing... and this is MAJOR... centralize your DLLs into a given BIN directory and always put your DLLs there and never put them anywhere else and if you have other people on the development team make sure their working directories are exactly the same as yours.... relative positioning is crucial.... something like this will work... \ \MyProjects\FooBarSystem\Bin \ \MyProjects\FooBarSystem\ProjectA \ \MyProjects\FooBarSystem\ProjectB \ \MyProjects\FooBarSystem\ProjectC ... \ \MyProjects\AnotherSystem\Bin \ \MyProjects\AnotherSystem\ProjectA \ \MyProjects\AnotherSystem\ProjectB \ \MyProjects\AnotherSystem\ProjectC ... ...so if you need to setup the entire system on a new developer's workstation, just move the copy the whole system directory, such as "FooBarSystem" and keep the same structure... ...and, of course, this structure should mirror the structure of the code in you source control system, such as SourceSafe, for ease of use... ...and so on, and so on... ...Take care.
Hi All, When I try to compile a project group I get a permission denied when trying to compile one of the components. Here is the scenario. (For ease of understanding I'll name the component A,B, C etc...) ProjectA - Standard exe ProjectB - Dll, Binary Compatibility ProjectC - Dll, Binary Compatibility ProjectD - Dll, Binary Compatibility Project E - Dll, Binary Compatibility I have a project group created for this and all references point to the VBP and not the dll's. Here are the references. ProjectA (exe) references: ProjectB, ProjectC, ProjectD, ProjectE ProjectB has no references ProjectC has no references ProjectD references ProjectC ProjectE references ProjectB and ProjectC The order in which the files are listed in the VBG File(Which I understand is the build order) is.... Project=ProjectB Project=ProjectC Project=ProjectD Project=ProjectE StartupProject=ProjectA (exe) I get the permission denied error when the project group tries to compile ProjectE. I hope I have provided enough information. Thanks in advance, Brian Flynn
|
Mon, 12 Jul 2004 01:02:21 GMT |
|
 |
Mark Kamosk #3 / 9
|
 Compiling Project Group, getting permission denied
OOPs... I made a mistake in my pseudo code below... ...I meant to say this... ....anyway, the script goes something like this... Compile ProjectA ...Check-in all files ...Unregister the DLL ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done Compile ProjectB (which has a reference to ProjectA) ...Check-in all files ...Unregister the DLL ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done Compile ProjectC (which has a reference to ProjectB) ...Check-in all files ...Unregister the DLL ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done ...and so on... ...that's a seemingly slight (but actually major) difference... ...sorry about that.... ---Mark.
Hmmm... ...it could be a million different things, I say... ...however, since I once got saddled with the "Build Engineer" role on a project, I found a way out, its a long story, but here is my take... ....when I am developing and actually writing code, I am in the VB IDE with a project group open with all of the projects in it and (as you note below) I point any cross-project references to the VBP of the projects being referenced... ....I never compile a DLL in VB because VB takes control over when and where and how that DLL is registered and so on, which I don't like... ...when I need to compile 1 or all of the DLLs in the project, I use a script.... ...you can script is using WSH, VBScript, and the like, or... ....there is a great, cheap tool call VisualBuild, http://www.kinook.com , that can make it a lot easier... ....anyway, the script goes something like this... Compile ProjectA ...Check-in all files ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Unregister the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done Compile ProjectB (which has a reference to ProjectA) ...Check-in all files ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Unregister the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done Compile ProjectC (which has a reference to ProjectB) ...Check-in all files ...GetLatestest version of all files ...Checkout the VBP and the DLL ...Unregister the DLL ...Build a new DLL ...Register the DLL ...Checkin the VBP and the DLL ...Done ...and so on... ...whatever you think of it, it works... you have to maintain the script (of course) but I have used this with zero problems and was building an enterprise-level, distributed system with many DLLs in a matter of minutes... ...you have to think allot about circular references and order of dependency and that sort of thing, but once you have the script debugged, you are golden... ...By the way, here's a good, quick way to see if you have a polluted registry entries... go to VB, open >Project, >References, and start scrolling down... if you see more than 1 entry with the same name (which usually are your projects that were registered more than once on the same machine from different locations, or something similar), then you have some "bad" registry entries.... ...this, of course, is NOT a good thing, but it is quite common... ....Norton Utilities has a program called WinDoctor that can clean up some of these registry entries and (if you don't mind using an old tool) Microsoft's RegClean also is supposed to work (but I don't trust it anymore since they haven't seemed to update it in years).... ...anyway, that's my schpeel, HTH, IMHO, and all that... ...(post with more questions and if you get VisualBuild let me know and I can send you a sample script)... --Mark. Post Script: Oh yeah, one more thing... and this is MAJOR... centralize your DLLs into a given BIN directory and always put your DLLs there and never put them anywhere else and if you have other people on the development team make sure their working directories are exactly the same as yours.... relative positioning is crucial.... something like this will work... \ \MyProjects\FooBarSystem\Bin \ \MyProjects\FooBarSystem\ProjectA \ \MyProjects\FooBarSystem\ProjectB \ \MyProjects\FooBarSystem\ProjectC ... \ \MyProjects\AnotherSystem\Bin \ \MyProjects\AnotherSystem\ProjectA \ \MyProjects\AnotherSystem\ProjectB \ \MyProjects\AnotherSystem\ProjectC ... ...so if you need to setup the entire system on a new developer's workstation, just move the copy the whole system directory, such as "FooBarSystem" and keep the same structure... ...and, of course, this structure should mirror the structure of the code in you source control system, such as SourceSafe, for ease of use... ...and so on, and so on... ...Take care.
Hi All, When I try to compile a project group I get a permission denied when trying to compile one of the components. Here is the scenario. (For ease of understanding I'll name the component A,B, C etc...) ProjectA - Standard exe ProjectB - Dll, Binary Compatibility ProjectC - Dll, Binary Compatibility ProjectD - Dll, Binary Compatibility Project E - Dll, Binary Compatibility I have a project group created for this and all references point to the VBP and not the dll's. Here are the references. ProjectA (exe) references: ProjectB, ProjectC, ProjectD, ProjectE ProjectB has no references ProjectC has no references ProjectD references ProjectC ProjectE references ProjectB and ProjectC The order in which the files are listed in the VBG File(Which I understand is the build order) is.... Project=ProjectB Project=ProjectC Project=ProjectD Project=ProjectE StartupProject=ProjectA (exe) I get the permission denied error when the project group tries to compile ProjectE. I hope I have provided enough information. Thanks in advance, Brian Flynn
|
Mon, 12 Jul 2004 01:20:56 GMT |
|
 |
Robert Bal #4 / 9
|
 Compiling Project Group, getting permission denied
Brian, Hi. I've run into this too. I may be wrong in my deductions, but this has ALWAYS worked for me.... It SEEMS as if the DLL is still loaeded in memory, and therefore will NOT be overwritten. Simply shut down VB, and restart without running. You should be able to compile in order. Also, try saving after compiling each project. Finally, I've noticed on my (1GHz, 512 MB RAM) machine, that after compiling and writing is done, there is a few second delay, and my hard-drive churns. I assume that the process in not fully complete until after it has finished this...try waiting until afterwards to save the newly compiled project. Hope this helps! Bobert :) Quote: >-----Original Message----- >Hi All, >When I try to compile a project group I get a permission denied when trying >to compile one of the components. >Here is the scenario. (For ease of understanding I'll name the component >A,B, C etc...) >ProjectA - Standard exe >ProjectB - Dll, Binary Compatibility >ProjectC - Dll, Binary Compatibility >ProjectD - Dll, Binary Compatibility >Project E - Dll, Binary Compatibility >I have a project group created for this and all
references point to the VBP Quote: >and not the dll's. Here are the references. >ProjectA (exe) references: ProjectB, ProjectC, ProjectD, ProjectE >ProjectB has no references >ProjectC has no references >ProjectD references ProjectC >ProjectE references ProjectB and ProjectC >The order in which the files are listed in the VBG File (Which I understand >is the build order) is.... >Project=ProjectB >Project=ProjectC >Project=ProjectD >Project=ProjectE >StartupProject=ProjectA (exe) >I get the permission denied error when the project group tries to compile >ProjectE. >I hope I have provided enough information. >Thanks in advance, >Brian Flynn
|
Mon, 12 Jul 2004 03:28:42 GMT |
|
 |
Mike #5 / 9
|
 Compiling Project Group, getting permission denied
Quote: > Hi All, > When I try to compile a project group I get a permission denied when trying > to compile one of the components. > Here is the scenario. (For ease of understanding I'll name the component > A,B, C etc...) > ProjectA - Standard exe > ProjectB - Dll, Binary Compatibility > ProjectC - Dll, Binary Compatibility > ProjectD - Dll, Binary Compatibility > Project E - Dll, Binary Compatibility
This will happen if you've also used the "compiled" file as your compatibility file. Make a copy of the DLL and use that one for your compatibility file. The reason you get the error is because as soon as you run the DLL project in the IDE, VB loads the compatibility file, but then doesn't remove it from memory when you go back to design mode. Therefore, when you recompile, VB can't overwrite it. What I do is create a folder named Compatibility and copy all DLLs to that. Mike
|
Mon, 12 Jul 2004 04:34:09 GMT |
|
 |
Willy Van den Driessch #6 / 9
|
 Compiling Project Group, getting permission denied
Exactly. For some gibberish about the rules : http://users.skynet.be/wvdd2/General_techniques/Compiling/compiling.html -- Van den Driessche Willy For a work in progress : http://users.skynet.be/wvdd2/index.html
Quote:
> > Hi All, > > When I try to compile a project group I get a permission denied when > trying > > to compile one of the components. > > Here is the scenario. (For ease of understanding I'll name the component > > A,B, C etc...) > > ProjectA - Standard exe > > ProjectB - Dll, Binary Compatibility > > ProjectC - Dll, Binary Compatibility > > ProjectD - Dll, Binary Compatibility > > Project E - Dll, Binary Compatibility > This will happen if you've also used the "compiled" file as your > compatibility file. Make a copy of the DLL and use that one for your > compatibility file. The reason you get the error is because as soon as you > run the DLL project in the IDE, VB loads the compatibility file, but then > doesn't remove it from memory when you go back to design mode. Therefore, > when you recompile, VB can't overwrite it. > What I do is create a folder named Compatibility and copy all DLLs to that. > Mike
|
Mon, 12 Jul 2004 08:19:29 GMT |
|
 |
<mkamo.. #7 / 9
|
 Compiling Project Group, getting permission denied
Yes, of course I agree with the comments of MikeD and Willy, above. However, I guess I should point out something. That sort of strategy will not scale well. That is, if you have a large project with 20 DLLs, 10 component developers, 2 database architects/developers, 2 GUI developers, and who knows how many interdependencies, you will simply not be able to manage building the project manually-- at least, you will not be able to do it efficiently. Building that kind of project cannot be done effectively "by hand". Automation is a good solution. That's why I commented with a more scalable solution. Just thought I would clarify why I actually did not answer your question directly; rather I provided the answer to the logical extension of your quandary. This is, of course, not to say that the comments of MikeD and Willy are not helpful or correct. I do not mean to imply that at all. It is just that I was re-reading my response after seeing what they wrote and I realized that I really had not answered the "exact" question you had asked. Then again, I don't mean to over-qualify my remarks; it is just that I believe the could be misconstrued. Regardless, have fun with it. Right? Take care, and good luck. Peace.
Exactly. For some gibberish about the rules : http://users.skynet.be/wvdd2/General_techniques/Compiling/compiling.html -- Van den Driessche Willy For a work in progress : http://users.skynet.be/wvdd2/index.html
Quote:
> > Hi All, > > When I try to compile a project group I get a permission denied when > trying > > to compile one of the components. > > Here is the scenario. (For ease of understanding I'll name the component > > A,B, C etc...) > > ProjectA - Standard exe > > ProjectB - Dll, Binary Compatibility > > ProjectC - Dll, Binary Compatibility > > ProjectD - Dll, Binary Compatibility > > Project E - Dll, Binary Compatibility > This will happen if you've also used the "compiled" file as your > compatibility file. Make a copy of the DLL and use that one for your > compatibility file. The reason you get the error is because as soon as you > run the DLL project in the IDE, VB loads the compatibility file, but then > doesn't remove it from memory when you go back to design mode. Therefore, > when you recompile, VB can't overwrite it. > What I do is create a folder named Compatibility and copy all DLLs to that. > Mike
|
Mon, 12 Jul 2004 20:09:24 GMT |
|
 |
Sol Shapir #8 / 9
|
 Compiling Project Group, getting permission denied
I was faced with a similar situation though somewhat larger in scope. 17 dll's and custom OCX's and ActiveX Exe's as out of process servers. Trying to keep the dependancies was a major headache. Interestingly enough a solution came from a product VisualMake. It let me reset the dependancies, as it scans all the added projects, sets them in a proper order, verifies GUIDS etc., I just (well - few hours ago) run a demo for our team lead(s) and all 47 applications (that includes the standard EXE's) compiled without a hitch. I am not much for promoting software, but knowing how hard it is for us VB developers to keep track of all the issues, I felt that this may be worth mentioning. A 30 day demo (yes we ordered the licenced product <g>) can be found at: Visual Make. Contact info: Phone: (604) 512-0053
Web: http://www.mobi-sys.com Good luck, Sol. -- Opinions and comments are those of the sender and do not necessarily represent those of the client he/she represents.
Quote: > Hi All, > When I try to compile a project group I get a permission denied when trying > to compile one of the components. > Here is the scenario. (For ease of understanding I'll name the component > A,B, C etc...) > ProjectA - Standard exe > ProjectB - Dll, Binary Compatibility > ProjectC - Dll, Binary Compatibility > ProjectD - Dll, Binary Compatibility > Project E - Dll, Binary Compatibility > I have a project group created for this and all references point to the VBP > and not the dll's. Here are the references. > ProjectA (exe) references: ProjectB, ProjectC, ProjectD, ProjectE > ProjectB has no references > ProjectC has no references > ProjectD references ProjectC > ProjectE references ProjectB and ProjectC > The order in which the files are listed in the VBG File(Which I understand > is the build order) is.... > Project=ProjectB > Project=ProjectC > Project=ProjectD > Project=ProjectE > StartupProject=ProjectA (exe) > I get the permission denied error when the project group tries to compile > ProjectE. > I hope I have provided enough information. > Thanks in advance, > Brian Flynn
|
Tue, 20 Jul 2004 07:49:28 GMT |
|
 |
Willy Van den Driessch #9 / 9
|
 Compiling Project Group, getting permission denied
I downloaded the tool. It is a great product but it has one - IMHO - flaw : When I have the following dependency : Project B ----- references -----> project A And I change the source code of project A, only project A should be recompiled. The tool also recompiles B. Projects should only be recompiled if the source (or relevant project settings) change. Not because a dependent component was recompiled. The whole idea of binary compatibility is there to ensure that things will continue to work. It is still a great product. It lets you change projects settings on multiple projects. We have a lot (200+) of projects so that could be a *very* pleasant feature. -- Van den Driessche Willy For a work in progress : http://users.skynet.be/wvdd2/index.html
Quote: > I was faced with a similar situation though somewhat larger in scope. 17 > dll's and custom OCX's and ActiveX Exe's as out of process servers. Trying > to keep the dependancies was a major headache. > Interestingly enough a solution came from a product VisualMake. It let me > reset the dependancies, as it scans all the added projects, sets them in a > proper order, verifies GUIDS etc., > I just (well - few hours ago) run a demo for our team lead(s) and all 47 > applications (that includes the standard EXE's) compiled without a hitch. > I am not much for promoting software, but knowing how hard it is for us VB > developers to keep track of all the issues, I felt that this may be worth > mentioning. > A 30 day demo (yes we ordered the licenced product <g>) can be found at: > Visual Make. > Contact info: > Phone: (604) 512-0053
> Web: http://www.mobi-sys.com > Good luck, > Sol. > -- > Opinions and comments are those of the sender and do not necessarily > represent those of the client he/she represents.
> > Hi All, > > When I try to compile a project group I get a permission denied when > trying > > to compile one of the components. > > Here is the scenario. (For ease of understanding I'll name the component > > A,B, C etc...) > > ProjectA - Standard exe > > ProjectB - Dll, Binary Compatibility > > ProjectC - Dll, Binary Compatibility > > ProjectD - Dll, Binary Compatibility > > Project E - Dll, Binary Compatibility > > I have a project group created for this and all references point to the > VBP > > and not the dll's. Here are the references. > > ProjectA (exe) references: ProjectB, ProjectC, ProjectD, ProjectE > > ProjectB has no references > > ProjectC has no references > > ProjectD references ProjectC > > ProjectE references ProjectB and ProjectC > > The order in which the files are listed in the VBG File(Which I understand > > is the build order) is.... > > Project=ProjectB > > Project=ProjectC > > Project=ProjectD > > Project=ProjectE > > StartupProject=ProjectA (exe) > > I get the permission denied error when the project group tries to compile > > ProjectE. > > I hope I have provided enough information. > > Thanks in advance, > > Brian Flynn
|
Tue, 20 Jul 2004 09:19:05 GMT |
|
|
|