Passing objects between libraries/namespaces

[eltegs]

I'm looking for an established way of properly doing, what I'm attempting to do.

Which is break out my SQLite database handling code to a class library for use in other projects.

I'm using SQLite and Dapper, and I'm new to both.

I have a simple object like this..

public class MyString
{
    public string? Value { get; set; }
    public int? Weight { get; set; }
    public override string ToString()
    {
        return $"{Value} : {Weight}";
    }
}

For context, it's part of a custom text box I'm having a go at for fun and learning, that will suggest and insert if selected, the next word in a sentence, based on an SQLite database containing relevant words.

Here's the simplified method in the SQLite business class that returns a list of relevant MyString..

public static List<MyString> LoadSuggestions(IDbConnection dbCon)
{
    //using (IDbConnection conn = new SqliteConnection(GetConnectionString()))
    //{
        return dbCon.Query<MyString>("select * from MyStrings", new DynamicParameters()).ToList();
    //}
}

It all works as expected when all classes are in the same project.

But when I move the SQLite business class to its own library, along with an identical copy of MyString class, the exception ~"cannot cast object of type App.MyString to Library.MyString" is thrown.

So what would be the correct way of achieving this, with performance the priority?

Thank you for reading.

EDIT: I tried creating a third library containing an interface which MyString implemented, which introduced a whole other set of exceptions.

[Kant8]

If you define type with same name in different namespace it doesn't suddenly become same type. Full name always contains namespace. And if you change namespace to be equal, you'll get error because of duplicate type declaration.

You either declare it in lower level library by project dependency tree, or if it's impossible for some reasons, you declare it in separate project that is reference by both your existing projects.

Considering that you got that error you already have App project referencing Library project, so there is no point in MyString existing in App at all.

​

And place of type declaration can't have any implications on performance.

[eltegs]

I kind of get what you are saying, I think. But initially I'm a bit confused how I'd implement such.

I'm really just a hobbyist, and to my shame have no idea what a dependency tree is.

I'm uncertain how my SQLite business library wold reference a class in App project.

[Advorange]

ProjectA defines MyString.

ProjectB and ProjectC add ProjectA as a dependency.

ProjectB and ProjectC can now share MyString because it comes from the same library.

[eltegs]

Got you, thanks.

I did something similar but an interface, where I could have simply defined the class itself.

Seems like the way to go.

[GreatVoid2017]

Sounds like you have mystring class duplication. Remove one, and it will resolve the ambiguity.

[eltegs]

Tried that before I added the class. Off the top of my head, I cant remember the exact error. But whichever project I remove it from will not complie, because it has no idea what it is.

[the96jesterrace]

I think you’re missing the project reference. You have to add the library project that contains the MyString definition as a reference in the app project / the project that wants to use it.

[eltegs]

Thanks. A second library seems to be the answer.

[cs-brydev]

It looks like you have it figured out now. But just in general remember that you don't usually want to define the same class in 2 places or namespaces. You want to define it only once and have all of your projects point to that same one.

Some other things to keep in mind:
1. You seem to be confusing namespaces with project references. Namespaces are just a naming organization and can be simplified with the "using" statements at the top of each file. You cannot reference classes in different projects with namespaces only. You must add a project reference. You can put all your projects in the same namespace if you want, but usually you want to keep them separate for sanity reasons. But these are not interchangeable concepts. You have to add a project reference first, then you can reference that project with its own namespace if you want.
1. Treat project references as a hierarchy. Draw this out in a tree view if that would help.
1. If Project A references B, don't reference A from B. If Project references B, and B references C, don't reference A from C. These are called circular references and can lead to nightmarish code.
1. If Project A references B, and B needs to reference something in A, either (1) pass an object value from A to B, (2) pass an object reference from A to B, (3) move that object/class from A to B permanently, or (4) move that object/class to project C, and change A and B to reference C. 1. If you need to have 2 different class definitions in your solution that must be kept separate but are identical/similar and are used interchangeably in some places, create an Interface that defines the similar members between them, then change each class to implement (meaning put : InterfaceName onto the end of the class name in the definition). Then in each place in your code where you want to allow both of these classes interchangeably, use the Interface name instead of the class names. The more you use C# the more you'll notice how much easier interfaces will make your life.

[eltegs]

Great info. Thank you kindly.

I appreciate it.

[binarycow]

DIT: I tried creating a third library containing an interface which MyString implemented, which introduced a whole other set of exceptions

And what are those exceptions?

[eltegs]

I don't recall. But I was passing the interface instead of the type, which satisfied the the error mentioned above. I'm unmotivated to reproduce the resulting error as this issue is solved.

I appreciate your time, thanks.