Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
Austin1 Honored Contributor.
Honored Contributor.
448 views

Visual Studio - build/debug/compile behavior, Native multi-project solutions vs. Managed multi-project solutions

Visual Studio 2013, Visual COBOL 2.2

Please confirm as to whether this is expected or default VS behavior or not.

Assume a Native solution with two projects and a Managed solution with two projects

It appears that Visual Studio behaves differently on Native multi-project solutions vs. Managed multi-project solutions in respect to the following:

When you click DEBUG at the top menu of VS and then choose either Start Debugging or Start Without Debugging ...

on a Native solution, it will build only the first project (program) (the one designated as the start-up-project) of say, a two-project (two-program) solution, before it starts it,

whereas on a Managed solution, it will build both projects (programs or classes) of say, a two-project solution, before it starts it.

On both the Native solution and the Managed solution, the Configuration Manager has Build checked for both projects of each solution.

Thanks,

Austin

0 Likes
4 Replies
Micro Focus Expert
Micro Focus Expert

RE: Visual Studio - build/debug/compile behavior, Native multi-project solutions vs. Managed multi-project solutions

Actually managed solutions and native solutions work in the same manner. Different projects within a solution are not related to each other unless you create a dependency from one to the other.
In managed code you can add a dependency on another project by adding a reference to that project in the references folder.

In native code you add a dependency to another project on the Dependency tab of the Solution Property page.

When these dependencies are in place the dependent projects will always be built first, if required, whenever the main project is started for debugging.
Micro Focus Expert
Micro Focus Expert

RE: Visual Studio - build/debug/compile behavior, Native multi-project solutions vs. Managed multi-project solutions

While I agree that's how it's supposed to work in principle, I've never been able to discourage Visual Studio from building everything in a managed solution when asked to start for debugging.

That's why I nearly always build from the command line using:

msbuild file.cblproj /p:BuildProjectReferences=false /p:Platform=AnyCPU

(Feldman's make got dependency-graph construction correct in 1976, but apparently it's still beyond the capability of Visual Studio.)

Then if I need to debug, I start the program and attach the debugger to it. I only use start-for-debugging if I really need to debug it from startup.
Micro Focus Expert
Micro Focus Expert

RE: Visual Studio - build/debug/compile behavior, Native multi-project solutions vs. Managed multi-project solutions

Austin,

In both managed and native projects Visual Studio will check that the startup project is up-to-date and rebuild if necessary, and will also build any dependencies. Do you, by any chance , have a reference to your second project from the first project in the managed case? If you do, that will explain why it is also being checked.

Gael
Highlighted
Austin1 Honored Contributor.
Honored Contributor.

RE: Visual Studio - build/debug/compile behavior, Native multi-project solutions vs. Managed multi-project solutions

Wow! Between the three of you, I would say you nailed the answer with a sledge hammer! Thanks!

Chris: Thanks for reminding me that I had a reference in one of the projects of the Managed solution, tying it to the other project, which apparently explains why both were compiling each time when I used the DEBUG option. Also, thanks for pointing out the Project Dependencies options on the Native solution.

Michael: Thanks for the command line build template; I would have never attempted that without your crib note. Although these days, the command line would be a last resort (same for attaching the debugger). Also, thanks for the attribution to Dr. Stuart Feldman of Bell Labs for "make" (1977); I'll be sure to memorize that for my finals. I suspect that you are a Unix type, but there's nothing wrong with that. :-)

Gael: Yes, I have a reference in the start-up project pointing to the other project, in the managed solution, and I guess that explains the behavior. (I'm doing a face-palm as I type this.) Thanks!

I will say this - as far as VS's checking to see if a [managed] solution/project is up-to-date and deciding to rebuild (or not) accordingly - even though I understand that this is the way it's supposed to work, my experience is that it rebuilds it regardless (which may be what Michael was alluding to). And I believe that's a Visual Studio thing, not a Visual COBOL thing. I have even gone to the solution's configuration manager to try to turn off this behavior (which I don't like to do, as I will forget that I have done this). Of course, we also know that I can, in the Solution Explorer, right-click on the appropriate items individually and build/rebuild/compile them as well.

Anyway, Thanks again, all !!!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.