SolutionBuild.Build(true) resulting in dead-end (not determining)

[arminku]

The buildSolution Method caused me some troubles using TcXaeShell, since it will block the code. Sadly I was not able to solve the problem.

Used a workaround by calling SolutionBuild.Build(false) and waiting the buildingstate to become "done". Worked like a charm, but there might be more sexier ways..

VisualStudioInstance.cs:

public void BuildSolution()
{
    visualStudioSolution.SolutionBuild.Build(false);
    System.Threading.SpinWait.SpinUntil(() => visualStudioSolution.SolutionBuild.BuildState== EnvDTE.vsBuildState.vsBuildStateDone);
}

[stefanbesler]

same here, at least sometimes, I can not always reproduce the issue though (it is more like a 50/50 chance). I got into similar trouble on one of my projects when using the combination

solution.SolutionBuild.Clean(true);
solution.SolutionBuild.Build(true);

as you are doing it. It can be solved by either removing the Clean(true) part or using @arminku solution. It is not pretty, but I think this is a bug in dte that can be bypassed with this solution.

[sagatowski]

Good catch. I haven't seen this issue with the TcXaeShell, but I haven't been using it so much either. @arminku you are welcome to create a PR if you want!

edit: and if you don't want, I can add your fix :-)

[stefanbesler]

@sagatowski do you actually need to build the solution here anyway? Wouldn't it be better to just check all objects (ITcPlcIECProject2 -> CheckAllObjects for all PLCs found in the solution) and then check the error count? None instantiated objects don't show build errors even when they contain syntax errors and hence, specifically libraries will never show build errors.

[sagatowski]

@stefanbesler The problem with CheckAllObjects is that it does just that, checks all function blocks/functions that might not even be in use. By building we make sure to only build the FBs/functions that actually have a reference in the test program of the library. I've seen numerous instances where developers have FBs that are not compiling, but doesn't cause any problem as they are not referenced anywhere. In this case the only thing we want to actually check/compile is what have tests defined for, not anything more that might be there in the library.

[stefanbesler]

I've seen numerous instances where developers have FBs that are not compiling, but doesn't cause any problem as they are not referenced anywhere.

doesn't seem like a good coding practice, it would be better if these developers would disable none compiling code by excluding the FBs from the build :-D . But I see, if this should be supported, then CheckAllObjects isn't the solution to the problem, even though it seems nicer on paper than the workaround from @arminku

[sagatowski]

I've seen numerous instances where developers have FBs that are not compiling, but doesn't cause any problem as they are not referenced anywhere.

doesn't seem like a good coding practice, it would be better if these developers would disable none compiling code by excluding the FBs from the build :-D . But I see, if this should be supported, then CheckAllObjects isn't the solution to the problem, even though it seems nicer on paper than the workaround from @arminku

I fully agree with you, and that's what I usually tell developers. It's just more a matter of fact that I don't want to enforce certain coding practice on developers by applying this rule as there are probably enough of developers that wouldn't agree on this rule :-)

[sagatowski]

An addition to the above. Another reason (at least right now) is that if you develop a library that uses the new Tc3_Vision-library and do a Check all objects, you get an error in the build even though you have no errors in your own code. This would mean that ANY library you develop would always fail to be used with the TcUnit-Runner.

Beckhoff are aware of this bug, but if/when a fix is done no-one knows.

[stefanbesler]

It will be ready in 1 month I guess (valve time)

[sagatowski]

Solved in afe859395c0d53935baa02d4ef87a733decaaedd. Thanks @arminku and @stefanbesler!