I've entered a project that used the architecture where all the utility classes were stored in the same project as the plugin. That's fine as long as there's only a few plugins with different utilities.
I noticed, however, that as the number of plugins has grown, many of the individual utility classes overlap. So, I'd like to pull out all the utilities into a single, separate project. My fear is that it's going to be too complicated to maintain once I'm leaving the customer as they're not technically keen.
The best solution I've got this far is following this blog facilitating ILMerge. However, I wonder if there's a simpler way. The optimal approach would be if I can make the CRM "see" the utility DLL just by uploading it. Can I somehow register a non-plugin, non-executable DLL that the plugins can refer to?
No, if you are using CRM Online this is not supported.
If you are running CRM On-Premises you could deploy the utility DLLs to disk or register them in the GAC. In either case you need to make sure to keep them updated on each CRM server - if there is more than one.
Related
When we want to use a native shared library, we have to have the header files. So when we publish the software, others do not have the header files and they can not use the library.
But the managed library does not need any headers. Because you can simply use add reference in Visual Studio and use Object Browser to see all the classes and namespaces.
So when we publish our application with managed library, not only others can use our library in their own project (whether it is obfuscated or not), but also they can decompile it and see the whole source code if it is not obfuscated.
Is it true?
How can we secure our managed library?
Well, that's perfectly safe. In practice the main impact of having users able to see (a decompiled approximation of) the workings of the library is that you sometimes get a higher quality of bug report from them.
Software companies like Microsoft manage to eke a living despite consumers being able to decompile their libraries, or indeed just read the published source.
But if you really want to prevent it then being managed does not preclude being obfuscated.
There are several obfuscators available, and if you really want to get in the way of your users, you can ilmerge in the library to a make a single obfuscated executable, so they can't even use the library, never mind give you useful feedback copy your code.
I have a question regarding development architecture and what would be considered to be the ideal organization of code and logic.
I am working in a company that has multiple C# solutions, with multiple projects accessing multiple databases. Some projects access only one database, some others access all of them, and so on.
Right now, the management of each database is made inside each project. I have been thinking about creating libraries to unify all this process.
Could somebody give me some insights regarding this? What would be the best way to work on this?
I've been thinking about centralizing all the Database logic inside a solution, with separate projects for each Database. This way I can create Class Libraries that will compile DLLs for each of them, that can be referenced between projects and solutions.
What do you think about the concept above, specially working using Entity Framework?
Thanks in advance.
We have a very similar situation.
For each database, we have a separate class library project. The project contains the context, entities and associated migrations.
Each product references the class library or class libraries that correspond to the database(s) it works with.
When we first started, each developer would check out the class libraries, build locally and reference the locally compiled DLL (which we copied to a known location with a post build event). It turns out that it's remarkably easy to setup your own NuGet server and publish updates to that server. We transitioned to that solution a few months back, and it works wonderfully. There are also a number of hosted NuGet providers.
This should be the way to go yes. I would create a solution for that purpose, abstract all database connectivity logic there and then use it from other solutions just handling different ConnectionString's.
I recommend to take a look at NuGet if you already haven't, you will have many advantages with this package manager for sure!
I think one centralized database which has all the common entities among your applications can be useful here. if you want to keep the other databases is fine too, you can use replication to transfer data from master database to other databases and consume them in their applications
I would like to know which is the best way to organize the dll tools.
For example, I can have a project that has all the class tools the the company has been implement. For example, class to work with strings, class to work with files... and so on. I mean, a generic dll with tools that I can use in many projects. This would be a generic myCompaty.Utils.dll for example.
Other way it to have many dlls, of for each type of work. For example, I could have a myCompany.Utils.Files, other myCompany.Utils.Strings... etc.
With the first option, I would have only one dll, but if two persons need to add or fix something, only can work one person, because if two persons work at the same time, when one of the person compiles the new dll, the other person loses the work.
If I have many dlls, one for each kind of type of work, then is more difficult that two persons need to modify the same dll, because it's possible that each person is responsible of one of the dlls. However, the problem is that in this way, when I deploy the application, I would have a lot of dlls in the program directory.
So I would like to know which is the best practice when is created dlls.
Thanks.
From your question it is clear that you are using no versioning system. Try checking out something like Tortoise SVN - then, you will have no problems with several people working on same piece of software.
Regarding DLLs - I would go with having multiple DLLs, each only containing a specific type of utility methods. It will make deployment simpler. If you would do the opposite, that is, have a single DLL for all your utility methods, you would need to redeploy it everytime anything in it changes - you change the code responsible for working with files, you have to ship the whole DLL that will contain unrelated code, too. Whereas if you'll have multiple DLLs, you only need to redeploy the one that has really changed.
Basically it's going to depend on the number of classes, interfaces and delegates that your library is going to own.
Imagine the case you've 3000 classes in your "Company.Shared.dll" and you're developing a Web application. 600 of 3000 classes are for mobile development. What's the chance of using them in your Web application development? Zero.
So why you'd be deploying a 3000-classes-assembly for a Web application development if you only need Web development-related classes? Library size is greater than a Web-specific one as first can contain code for a lot of things which wouldn't be working in Web development.
For that reason you'd have a shared library called Company.Shared.Web.dll and a common to all development scenarios called Company.Shared.dll.
You can use above logic for other cases and scenarios.
Apart from the versioning system, (should be a must when more than half developer works on a project), it's really crazy that your organization allows everyone to change the base library (or libraries) on which every other project depends on. This will be evolve in a mess very quickly.
In my shop only one/two people are allowed to change anything there. And these guys are the most skilled and valuable colleagues.
For the subdivision of functionality present in the library I am not concerned with the big one DLL. It's true that I need to redistribute all even when we change a little bit of code (and when your code is mature and well tested this happens very rarely), but keeping track of every dll shipped for this project or for that project outweights the cost of the single one DLL
i have a project where i do something i have same copy from another who have do something in it later i have a thing to do currently.
so that's three copy and i am unsure that i am not confused with it. sometime i call wrong copy for finding the thing i want from them.
without using any software outside our office window any trick to manage all project or how i can manage them and make them one copy.
the same problem with some other problem come with when the same script used in two software , website who are used same script with have a small difference in both.
so i want to know how exactly all other manage them. i want to have a answer with .net plateform.
There are several source control solutions that have plugins to integrate directly with Visual Studio. I would recommend looking into Subversion. Currently at my office we use Vault, but it has some short comings, especially when it comes to renaming or moving a file and then editing it prior to a check in.
http://ankhsvn.open.collab.net/
http://www.sourcegear.com/vault/
I recently started a small pet project. It's written in C# with ASP.NET MVC3. As it's grown, my needs for source control also has grown. Here's what I've done:
Day one, I placed my project in a Dropbox folder. That way, I could reach my project files from all my computers (and even my iPhone).
A few weeks later, when I first had to make some serious changes and neede a fallback, I created a Mercurial repository in my Dropbox folder and commited all my code. I've got a blogpost on that here: http://csharptutorial.blogspot.com/2011/06/using-dropbox-with-mercurial.html. Mercurial is a great versioning system, because it doesn't require a server installation and your repository is copied in full to all locations where it's checked out.
Now, I'm looking at moving my project over to BitBucket (http://bitbucket.org/) where you also share and discuss code with others.
A good alternative to Mercurial is Git, using github.com in stead of bitbucket.org. Both have a learning curve, but they both represent modern version control tools and is well worth having a look at.
Source control and discipline.
You need to get an approach and method for managing your source. A source control system is essential for this. I use SVN and Ankh, as does Clayton.
However, you need an approach for using this. I always have branches. You can have development branches and merge these changes into a release branch when your code has passed all the tests. This way takes a discipline and time, but you need to do this to build quality into your system.
Over time, the code base I maintain has grown exponentially. We have a variety of different utility classes, webparts, event receivers, console applications, and more.
Typically, each webpart lives in a separate DLL (one solution and one project per web part). Our utility classes have also been largely separated out into their own separate DLLs (this includes any specialized list access classes that get grouped with their beans together in a DLL). This has led to a large amount of solutions which has become more difficult to maintain (upgrading each solution to Visual Studio 2008, or simply just trying to find out the maze of DLL references).
With my discovery of the SharePoint Guidance, I'm re-evaluating our current code structure. For example, it looks like they recommend combining all of your specialized list access classes into a Repository (we've done completely the opposite so far by splitting them into DLLs based on what "solution" the code is for).
Questions: How should I be organizing my code? How do you decide what goes into a solution vs project vs folder or what goes in a namespace? One solution per web part?
I usually organize my code by functionality. Let's say I've got an extranet project and some code for some intranet webparts, I seperate it out into a Extranet and an Intranet project, and seperate the different classes of code (eventreceivers, timerjobs, webparts, etc.) into different namespace.
That way, I can deploy (sub)sets of functionality to different farms if I want to, and when editing code I got everything that depends on one another in the same place :)