ScadaServerShell built after its .NET Framework target was aligned with the framework used by ScadaAgent; confirm the actual project targets before changing them because the reported Shell version was later corrected.
Inspect the project targets before changing references
Prerequisite: open the solution in Visual Studio 2017 and load the ScadaServer solution. The build was being run in Release configuration according to the provided build instructions; keep that configuration consistent while diagnosing the reported missing reference.
- In Solution Explorer, open the properties for ScadaServerShell and read its Target framework value.
- Read the Target framework value for ScadaAgent, the project identified in the build discussion as using .NET Framework 4.7.2.
- Write down both values before editing. The initial report described ScadaServerShell as 4.6.1, but a later correction stated that it was 4.7.2. Use the current project properties, not the earlier recollection, to decide whether there is a mismatch.
Check: you have a confirmed target value for both projects and know whether ScadaServerShell is actually below ScadaAgent's 4.7.2 target.
Align ScadaServerShell with the referenced project
A project reference carries build-time compatibility requirements. If ScadaServerShell targets an earlier framework than the project or assembly it references, Visual Studio can report a reference problem even when the reference path itself is correct. Matching the consuming project's target to the referenced project's target removes this framework mismatch as a cause.
Prerequisite: confirm that ScadaAgent targets .NET Framework 4.7.2 and that ScadaServerShell currently targets .NET Framework 4.6.1. If both already show 4.7.2, do not change the framework; proceed to inspect the reference and build output.
- Open ScadaServerShell project properties and select the target framework setting.
- Set the target to .NET Framework 4.7.2, matching ScadaAgent.
- Save the project and allow Visual Studio to reload it if prompted.
Check: reopen the property page and confirm ScadaServerShell displays .NET Framework 4.7.2. Do not treat a property-page change alone as proof that the reference now builds.
Rebuild the reference path in Release configuration
After changing a target framework, rebuild so Visual Studio regenerates outputs and evaluates project references against the new target. A stale output can obscure whether the framework change resolved the original error.
- Select Release configuration, as used for the reported build.
- Build the referenced project, ScadaAgent, and confirm that it completes without an error.
- Build ScadaServerShell and inspect the first reported error in the output. Confirm whether the missing-reference message has cleared.
Check: ScadaAgent and ScadaServerShell both build in Release. If ScadaAgent fails, resolve that failure first; a dependent project cannot validate a reference to an output that was not successfully produced.
Separate framework mismatch from a broken reference
If the error remains after both targets match, distinguish a framework issue from a path or project-load issue. A framework alignment will not repair a reference that points to a missing project, an unavailable assembly, or an output that has not been built.
| Observation | Next check |
|---|---|
| ScadaServerShell target is lower than ScadaAgent's 4.7.2 target | Align the Shell target, reload, and rebuild. |
| Both projects target 4.7.2 but the reference error remains | Inspect the reference entry and confirm the referenced project or assembly is present and loaded. |
| ScadaAgent has a build error | Resolve its first build error before rebuilding the dependent Shell project. |
In the reference properties, verify that the referenced item is the intended project or assembly and that Visual Studio can resolve it. If the reference is project-based, confirm the project appears in the solution and builds. If it is assembly-based, confirm the referenced file exists at the configured path. Do not replace or delete a reference solely because the error text says “missing”; use the reference properties and build output to identify what is actually unresolved.
Check: the target values match and the reference resolves to an existing project or file. If the first error names a different dependency, diagnose that dependency rather than repeating the framework change.
Verify the complete ScadaServer solution build
A successful ScadaServerShell build confirms that its immediate compile step passed, but the solution-level build checks the broader dependency chain. Run the sequence specified in the repository's HowToBuild.txt with Release selected after rebuilding the projects.
- Build the ScadaServer solution in Release.
- Confirm ScadaAgent and ScadaServerShell complete without build errors.
- Review the final build result and output for unresolved references or downstream project failures.
Final verification: the solution build completes in Release with no missing-reference error for ScadaServerShell, and the project properties still show the intended matching framework targets.
ScadaServerShell framework and reference FAQs
What happens if ScadaServerShell targets .NET Framework 4.6.1?
If its referenced project targets .NET Framework 4.7.2, the target mismatch can produce a reference/build problem. Confirm both project properties and align ScadaServerShell to 4.7.2 when that is the actual configuration.
What happens if both projects already target .NET Framework 4.7.2?
Do not change the target again. Inspect whether the reference points to a loaded project or existing assembly, then build the referenced project and check the first remaining error.
What happens if the Shell project builds but the solution does not?
Build the full ScadaServer solution in Release and identify the first failing dependency or downstream project. A successful Shell build alone does not verify the complete solution build sequence.