[Migrated content. Thread originally posted on 25 November 2011]

Hello,

I have found a big problem working with solutions which have several types of COBOL projects. I will try to explain this the better.

For example, consider the following scenario:

-One solution having a main managed project that uses another managed project, and this last one has a reference to a native project. Let's say A to be the main managed project, B the second and C (the native one) the last.
The folder where A generates the final executable is set like '.\\x86\\bin\\Debug\\', and the same applies to B. C has to have B's output folder.
All goes well until now.

-Now I create a new solution having a new managed project that references C. Let's name it as D. I include C inside the solution, and I change C's output folder to be pointing to D.
All ok.

But what happens when I come back to my first solution? Visual Studio tells me that something has been changed in project C (I could not apply the changes if I do not want to, but they will be applied next time I open the solution). Project B has not able to find the C's reference, and A does not find B's. And any try to repair this does not work until... well, until something happens that I cannot stil explain. Yesterday I bumped into this problem and it was solved apparently without my intervention.

Today I am again with the same issue. It is a pity that the project's configuration could not be isolated per solution. I am beginning to think that it will be better working with dll's instead of projects, when I want to use a reference to a native project.

Any suggestions to deal with it?

Thanks

Hi voyager,

There are a number of possible solutions to this issue.
Really, this point illustrates the strengths and benefits of moving to managed COBOL, where project references can easily ensure that managed executable code all ends up in the right place.

For native projects, we have to do a bit more work.

The first, possibly simplest, solution - if it works for you - is simply to direct the output of all of the projects across all solutions into the same folder. This way, output from project C goes to a single location regardless of which solution it is built from. It means that project A's output is mixed with project D's, and you would have to ensure that the correct solution is built and up to date before running the output (although this won't be a problem if you're running from within the IDE).

A variation on that is to put all of the projects into the same solution, and again set a common output path. This has the advantage that both 'solutions' (i.e. target applications) get built at the same time and share the same common projects. You no longer have the risk of one application becoming out of date just because the other has been built.

If you want to keep the solutions separate, and have different output paths for project C depending upon which solution it is built from, this is possible using project configurations. From the build configuration manager, you can create a new copy of the current configuration for project C, and set one of the solutions to use this new configuration in favour of the original. You can then change the output path for project C by configuration.

It is possible to create a similar effect by using macros or environment variables.

Another possible solution is to use pre-build events in order to pull the output of project C into the output path for project A/D at build time.

There are numerous mechanisms of achieving the same effect by editing the project files directly, if you are familiar with msbuild files.

Finally, if you do decide to add a reference in projects A & B to the .dll created by project C, you can set the CopyLocal property of the reference to True, thereby causing the build of projects A & B to copy the .dll into their own output folder as part of the build. You can use project dependencies to ensure that project C always gets built before any of the projects that rely upon its output.

Thanks for posing an interesting question, and I hope this gives you some useful options for how you choose to resolve the issues. It has been a useful exercise thinking up solutions, and one that demonstrates the power of Visual COBOL in the Visual Studio environment.

John

---