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

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

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

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 :)

references point to the VBP

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

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

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

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.

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