We Keep Coding

Migration from EntitySpaces to EntityFramework

Our legacy application is using EntitySpaces for database access but since ES is EoL for several years and is causing some performance issues on our application we're thinking about switching over to EntityFramework.
Is there an easy way to do this without completely rewriting all of our extension classes?

EntitySpaces is alive again and the API has been updated and is far more streamlined. It's a single DLL Nuget install too. What kind of performance issues, I'd love to hear about the issues
https://mikegriffinreborn.github.io/EntitySpaces/

I've been thinking about this for a while. I don't think there is going to be a simple solution to move away from EntitySpaces and move to EntityFramework. But the approach I would, and probably eventually will take, is if you haven't already, add an interface to each of the methods in your Business logic that inherits from the data classes and include every method you need.
Now, add a Database First EF model and create new business-logic classes for each entity/model to inherit from that interface you've made. Then you know every method that requires re-writing in EntityFramework(LINQ/Lambda). It's a slow process but this way you can do the migration over multiple release windows, slowly moving everything over, referencing the new EF business-logic models as-and-when you have time (and of course, any new tables can use EF straight away).

Class object sharing across C# and Android

I create a lot of object classes when I do programming. There are many situations where same object definition will be reused across multiple projects. In windows, I simply build them into .dll file library and include them as the project reference. Therefore, when I need to add additional properties or methods, I just need to do it once and I don't need to worry about go through all projects and manually update the object class definition.
Now, I'm given a project to build an Android application which requires several object classes that's being used within other projects (and must be synced). Of course, I can manually create them within Android and update them every time whenever there's a change, but this is very dangerous because one day in the future, it is very likely to be out-of-synced.
Anyone have suggestions on how to share class library across C# and Android?
Thank you

The only way I know how to do this is to use Xamarin which would allow you to write your entire Android application in C#.
The problem is Android and .Net use completely different runtimes that are not compatible.

I don't have a clear enough view of what your application does, but if you are using the C# objects on a webAPI and looking to keep your objects synced with the client app, you can use Breeze.js - this keeps your client/server biz objects synced. The classes get pulled in dynamically via a meta service call.

how to have only one project for different versions of .NET?

Well, I have a project, and by the moment I am using .NET 4.0, because I would like that this application is compatible with windows XP, because EF 5.0 is only for windows 7 and upper.
However, I would like to implement some parts of the application with the features of .NET 4.5, such as EF 5.0.
So for my database access I have a reposotry class that now use EF 4.0, this is a independent dll, so I can create other repository dll that use EF 5, and in my project import both dlls, then I can instantiate the correct repository according to the version of EF 5.0 that I can use. This is a paramater in the config file. is this the best way?
I ask this because I don't know where I must declare my interface. because my repository classes need to implement this interface, but then this tie my dlls to my application, but I need to use this repositories in two different applications, so I want to implement once, and use in many applications. I want independent dlls, because now are two applications, but in the future, can be more.
The reason to want to use an interface in the application that uses the repositories is because I would like to instantiate at runtime the correct repository, according to the config file settings. So in the fututre I can implement new repositories and there is no needed to change the code.
EDIT1: I read about multi targeting, but if in my project I use features for example of .NET 4.0 and I want to complie for 3.5, I get an error because this feature does not exist in 3.5. That's correct. Then the only way is to mantain two different projects? It would be a double work.
Thanks.
Daimroc.

So for my database access I have a reposotry class that now use EF
4.0, this is a independent dll, so I can create other repository dll that use EF 5, and in my project import both dlls, then I can
instantiate the correct repository according to the version of EF 5.0
that I can use. This is a paramater in the config file. is this the
best way?
You can go this route and I don't really see an issue with it unless you think that this could cause maintenance/development headaches in the future. There are a couple of other things that you can look into doing. I think both are completely valid and probably just personal opinion/preference.
Modules You can go a modular route where your repository DLLs are potentially loaded dynamically. Look into Microsoft's Unity library. This should allow you to create an IModule in each of your repository DLLs that will set up your application as needed. Then just create a UnityBootstrapper class to tell it how to find your modules (manually add them, look in a directory, etc.). This should allow you to hot swap your repository DLLs and not have to worry about setting a config file if you don't want to.
Preprocessor Directives With preprocessor directives you get to define how your code will compile. Depending on how you have your classes structured this may be something fairly simple to set up or a complete nightmare that makes you want to abstract and refactor your classes. This question: Detect target framework version at compile time has an answer for handling different compile results depending on the target framework. Personally though, I like the modular route.
I ask this because I don't know where I must declare my interface.
because my repository classes need to implement this interface, but
then this tie my dlls to my application, but I need to use this
repositories in two different applications, so I want to implement
once, and use in many applications. I want independent dlls, because
now are two applications, but in the future, can be more.
The reason to want to use an interface in the application that uses
the repositories is because I would like to instantiate at runtime the
correct repository, according to the config file settings. So in the
fututre I can implement new repositories and there is no needed to
change the code.
Sounds like you need to create another library that is used to communicate between your UI and your Repository libraries. This can be a little tricky and overwhelming to set up just right. Basically you want your gateway DLL to house the interfaces and business objects. Your Application would reference this DLL and this DLL would reference your repositories.
Depending on your needs you may actually need to set up another intermediary DLL that would actually just house your interfaces and most basic utility classes. This would allow you to have your EF objects implement the same interface that your application is using without the need for your gateway DLL having to map your business objects and EF objects back and forth.
EDIT1: I read about multi targeting, but if in my project I use
features for example of .NET 4.0 and I want to complie for 3.5, I get
an error because this feature does not exist in 3.5. That's correct.
Then the only way is to mantain two different projects? It would be a
double work.
I believe you can get around this by using the Preprocessor Directives I mentioned above. Below is just an example of making a method handle work differently depending on if the framework is .NET 2.0; it's just an example and not tested. The DefineConstants will need to be set up, but this should allow you to handle 1 project for multiple framework targets while also being able to use newer .NET features as they are released.
public Person FindPersonByName(List<Person> people, string name)
{
#if DOTNET_20
foreach(Person person in people)
{
if (person.Name == name)
return person;
}
return null;
#else
return people.FirstOrDefault(p => p.Name == name);
#endif
}
I hope this was helpful and the best of luck in finding the right solution.

What is an easily maintainable way to share a common .net class library over many corporate asp.net mvc 3 web applications?

I've been struggling to do this in a way that fulfills all of my requirements.
Here is what we have in our library:
Base classes for controllers and services
Business objects (stores, departments, etc)
Common Partial Views (Login, Error, etc)
Base class for HttpApplication
General common code (read an INI file, create a db conn, etc)
The one requirement that has been giving me trouble is as follows:
Lives in one place on a server. (i.e. copy local = false)
This breaks because:
The DLL containing the HttpApplication class must be in the same directory as the web apps dll to launch. I haven't found a way around that. I'm ok with duplicating this code in every app, but would rather not.
The shared views don't like to work if I use Assembly.LoadFrom() to load the dll from the shared location. (I've been using this method to precompile my views)
Any namespace shortcuts in web.config break at runtime with compilation errors because the web.config is parsed before the assembly is loaded.
My question to you folks is how do you handle your common code in a similar environment?
The GAC seems to be more trouble than its worth, and we want all of our apps to be using the same code, and not have multiple apps on multiple versions and have to maintain all of that. Are there design patters/best practices that can guide us in this regard?
Also, as a bonus, if you can solve any of the problems above, that would be great, too.
Thanks!
Edit: I guess a question that follows is whether or not we should even have a directory with the common dll(s) on the server, or if they should only be deployed as projects are deployed/updated?

Firstly, you will want to separate out what you're trying to achieve. Don't create 1 library that does everything or you will have a Big Ball of Mud. Don't be afraid to create several maintainable libraries to achieve what you're after. Is there a specific reason it needs to be stored in one location?
For example, several of the items you mention are MVC or web specific. If you have items that can be reused by MVC, create a class library that contains MVC base classes you inherit and reference them in your project. Use the single responsibility principle as much as possible.
Regarding the other items you mentioned, like database connectivity, if it's reusable, abstract it out in a data access class library and reference it. Other simple operations like reading an ini file or creating a file, create another library and abstract it to easy to use methods.
I prefer to copy the library dlls locally. You never know when you will need to make changes to the library, but you don't want all of your projects to stop compiling. When you're ready to implement a new version of the library, copy the dll in and recompile.

Not sure why all the hate towards the gac. It was designed to handle this specific problem. Install your common dlls to the gac and all apps can see them. Need to deploy a new one, just re-install it in one place.

Best solution: Extension Methods or a New Class?

So I'll try and play devil's advocate on this one...
Hypothetically there is a Framework which services 2 or 3 different web sites. 1 basic function of the framework is to deal with all calls to a certain DB. When making a DB call the websites call a Framework DataSource object and get a generic Framework data object back.
Now for the websites to retrieve properties/methods that are specific to it's needs we've got 2 solution options.
Create a new Class, extending or wrapping the generic data object,
exposing more domain friendly properties & keeping any domain
specific functionality inside of this new class.
Instead of creating a new class, create extension methods inside the Framework to service each of these websites. So everything is
contained inside the Framework and can be shared between web sites
if 1 day needed.
Just to clarify here would be examples:
Properties:
NewObject.GetSiteSpecificProperty
GenericObject.GetProperty("GetSiteSpecificProperty") or GenericObject.GetSiteSpecificProperty()
Methods
NewObject.DoSomethingSpecificToThisWebsite()
GenericObject.DoSomethingSpecificToThisWebsite()
So what solution would you opt for? 1 or 2?
Cheers.

In my opinion when designing a Framework you want to keep as much solution specific aspects out of the Framework and have the calling entities handle that if possible.
Now I'm not sure quite how your framework will be used or by how many different websites\projects but going with option (2) means that now whenever a new website is added the framework now needs to go do work in order to complete this functionality. The work of using the framework in a custom way should be handled by the websites not by the framework. If this framework ever grows to use 10 or even 100 websites, this becomes an absolute nightmare to maintain and your framework ends up looking much less like a framework and more like a solution specific product. Going with (1) is a much cleaner solution. Basically keep your framework reusable and solution-agnostic as possible.
If you are designing a framework that will be used by many different projects and is designed to be around for a while I'd recommend reading Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)

Generally if you control the source of the class you're extending, I would extend it by inheritance instead of extension methods. Extension methods are great for adding custom functionality to classes you don't control, like .NET built-ins (String, Enum, IEnumerable) and other third-party objects. However, they can be hard to organize, and they're technically static methods, which you usually want to minimize in the interest of startup performance and memory footprint.
You may also find yourself in namespace and method resolution trouble by going with extensions; let's say you put the extension methods into site-specific libraries. If one site ever has to do the same site-specific thing as another, you must either include one site's library containing the extension method in the other site (exposing other things you may not want your code to know about, possibly containing duplicates of objects or extensions), or clone the code (violating DRY).

In my opinion, it's a better design to create a base class and use overrides for your site specific code. Although they could do it, it just doesn't seem like extension methods were meant for this type of operation.
Now if you're looking for a way to get different values using a shared framework on different websites, it seems like the web.config would suit that need. Each site will have it's own Web.Config, can you populate the specific property values you need in there, and have a single function to retrieve that value?

I would go for 1 because it keeps the framework general (and reusable) and specific functionality where it's used and where I would look if I were a maintenance programmer.
To share functionality I'd create a base wrapper class that the specific wrappers derive from.