views:

145

answers:

1

1st solution located: \Common\Controls\Controls.sln
and its project: \Common\Controls\Common.Controls\Common.Controls.csproj
Description: This is a library that contains this class:

public abstract class OurUserControl : UserControl
{
    // Variables and other getters/setters common to our UserControls
}

2nd solution located: \AControl\AControl.sln
and its project: \AControl\AControl\AControl.csproj
Description: Of the many forms/classes, it will contain this class:

using Common.Controls;

namespace AControl
{
    public partial class AControl : OurUserControl
    {
        // The implementation
    }
}

A note about adding references (not sure if this is relevant):

When I add references (for projects I create), using the names above:
1. I add Common.Controls.csproj to AControl.sln
2. In AControl.sln I turn off the build of Common.Controls.csproj
3. I add the reference to Common.Controls (by project) to AControl.csproj.

This is the (easiest) way I know how to get Debug versions to match Debug References, and Release versions to match Release References.

Now, here is where the issue lies (the 3rd solution/project that actually utilizes the UserControl):

3rd solution located: \MainProj\MainProj.sln
and its project: \MainProj\MainProj\MainProj.csproj
Description: Here's a sample function in one of the classes:

private void TestMethod<T>()
    where T : Common.Controls.OurUserControl, new()
{
    T TheObject = new T();
    TheObject.OneOfTheSetters = something;
    TheObject.AnotherOfTheSetters = something_else;

    // Do stuff with the object
}

We might call this function like so:

private void AnotherMethod()
{
    TestMethod<AControl.AControl>();
}

This builds, runs, and works. No problem. The odd thing is after I close the project/solution and re-open it, I have red squigglies everywhere. I bring up my error list and I see tons of errors (anything that deals with AControl will be noted as an error).

I'll see errors such as:

  • The type 'AControl.AControl' cannot be used as type parameter 'T' in the generic type or method 'MainProj.MainClass.TestMethod()'. There is no implicit reference conversion from 'AControl.AControl' to 'Common.Controls.OurUserControl'.

or inside the actual method (the properties located in the abstract class):

  • 'AControl.AControl' does not contain a definition for 'OneOfTheSetters' and no extension method 'OneOfTheSetters' accepting a first argument of type 'AControl.AControl' could be found (are you missing a using directive or an assembly reference?)

Meanwhile, I can still build and run the project (then the red squigglies go away until I re-open the project, or close/re-open the file). It seems to me that I might be setting up the projects incorrectly. Thoughts?

+1  A: 

You shouldn't make one solution for every project you have but have one solution that contains multiple projects (in your case likely all).

You can also make multiple solutions with overlapping contained projects. E.g. if you often only edit the core library create one solution that contains only your \Common\Controls\Common.Controls\Common.Controls.csproj project and create another that contains all three to edit the other two projects.

This will give you by far the best experience with Visual Studio (and you no longer have to care about matching debug/release and so on).

Foxfire
Thx for the response. While reading your answer, I started thinking: even though I've been dealt with a sln for each proj, the main sln eventually gets all projects added to it. Using my example above, Main Sln, contains all 3 projects. Technically, have I achieved what your answer suggests?
JustLooking
Btw, I just realized why the architect/mgr set up a sln for each project. Most of these projects are usercontrols (which eventually get applied to the main project). So, each individual solution will contain: the UserControl project (and all its code/classes), a Test project (that obviously tests the UserControl). So, each UserControl can be developed and tested on its own. I'm wondering if this is such a bad idea (and if this is the true cause of red-squiggly hell!)
JustLooking
No thats not neccessarily bad. Then make one solution that contains everything where you can edit stuff that depends on the object inheritance structure and you can leave your individual solutions to test the individual components.You could also make one project for all tests and one without.
Foxfire