I am trying to use Dotfuscator (CE) to help protect our ASP.NET MVC .ddl. Its a web application that will be distributed to clients and we need a way to protect our IP.
The problem is that it appears to break the application once completed. I've only got so far with disabling renaming on my Controllers namespace but I'm get null reference exceptions now.
Has anyone got Dotfuscator working with ASP.NET MVC DLL's? Google provides no possible blog posts or information.
Thanks.
Other details:
Visual Studio 2008 Professional,
Windows Vista Business x64,
Registered my Dotfuscator but not had an email with a download link for the upgraded CE edition.
Or can anyone suggest a relatively cheap tool that would work properly?
I don't think that will work because ASP.NET MVC relies so heavily on reflection.
I have successfully obfuscated an ASP.NET MVC application using SmartAssembly and the control-flow-obfuscation option it has. That does't change the name of your class members but instead changes the code in your methods into spaghetti code.
It is true that ASP. NET MVC relies heavily on reflection, and therefore you cannot obfuscate the type or properties which will be reflected. However, I would argue that there is no need to obfuscate most of this stuff anyway. Your controller names and action names are already public, since they appear in URIs. Your presentation models are essentially public as well, since they should be designed like your view, and since end-users can see your view.
Your controllers should be very lightweight, and simply bind objects from a repository to your presentation models. So there is little intellectual property to hide here.
The code you would actually want to obfuscate would presumably be your business logic, which can very easily live in a separate assembly. So my suggestion would be that rather than trying obfuscator after obfuscator, and trying to find one which seems to work (except for those bugs which you miss, but your users find later on), that you instead partition the code which is important to obfuscate and his not so dependent on reflection.
Related
I have inherited a mostly c# MVC application that has been around for years and is quite the collection of mySQL, stored procs, Web Forms, MVC, WebAPI, JS, jQuery, Angular, and I think there is some React in there as well. I am looking for a tool where I can start the application, get to a particular page, then look at what classes and methods were called to get there.
I know the application needs refactored and, frankly, completely rewritten, and that is happening. We just also need to support this tool as another team develops the next version.
Thanks,
Sammer
You can use my Runtime Flow tool to quickly find C# classes and methods responsible to display a particular page.
I need to create/publish a complex MVC site to several clients, each with mostly shared functionality but also custom stuff, such as client specific controllers / views / business logic etc. Most insist on hosting the site themselves, and have functionality they don't want others to know about.
Following reading this SO post and this, I've created a means for MVC Multi-tenancy, which seems to handle most scenarios.
As I can't attach to Stack Overflow, I have posted it here (no need to read it all - it's mostly screenshots!).
The basis is to have a generic project, referenced by several client projects. The client project can then have a similar structure to the generic and take precedence when I wish to use overriding code/controls/views.
As it's the foundation of the whole thing, I don’t want to implement something only to find everyone else does it in an easier/ better way.
My question is a bit wooly, but simple - Is there a better way?
Your architecture seems about right. I would just say that you have to be really careful about the generic thing and how the client's addons will talk to the core application.
I would do that by having a base project in the CVS with client's specific branchs referencing it (as in git submodule) so everyone can beenfit from the core.
Rolling out production and QA versions are also something that must be dealt with caution as you can end up with different version far from each other depending on the client.
I have an application that I have designed and this app has a pretty decent core dll that contains an API that my main view's exe uses. I would like to allow other developers to access this core dll as well but I don't want them to have as much access as me since it would be a security risk. What is the standard way of exposing my core dll? Are there any particular design patterns I should be looking at?
I'm using C#
Edit: my question was a little vague so here is some clarification
My program is deployed as a windows exe which references the core.dll. I want other people to create extensions which dynamically get loaded into my program at start up by loading dlls in the /extensions directory. The 3rd party dlls will inherit/implement certain classes/interfaces in my core.dll. I only want to give 3rd parties limited access to my core but I want to give my exe additional access to the core.
I should mention that this is the first time I have written a program that imports DLLs. Perhaps this whole method of allowing users to add extensions is wrong.
How do I modify/expose my API for
other developers?
To deliberately allow other developers to work with an API you've built touches on many things, which can be broken into two areas:
Resources (documentation, samples, etc) that makes it easier for them to understand (yes - basically an SDK).
Architecting, constructing and deploying your solution so that it's easy to actually work with.
Examples include:
By packing it in a way that suits re-use.
By using naming conventions and member names that others can easily follow.
Documentation, samples.
Providing the source code (as open source) if you're happy for them to modify it.
I would like to allow other developers
to access this core dll as well but I
don't want them to have as much access
as me since it would be a security
risk.
Ok, so this gets us right into the second area - the actual solution.
The problem you have is not a trivial one - but it's also quite do-able; I'd suggest:
Looking into existing material on plugins (https://stackoverflow.com/questions/tagged/plugins+.net)
Personally, I've found using attributes and Dependency Inversion to be a great approach.
There's also stuff like the Managed Extensibility Framework which you should consider.
The big issue you face is that you're into serious architecture territory - the decisions you make now will have a profound impact on all aspects of the solution over time. So you might not be able to make an informed decision quickly. Still - you have to start somewhere :)
The "design patterns" in terms of an API are more related to things like REST.
I don't want them to have as much
access as me since it would be a
security risk
Then i would (for the sake of maintenance), layer on top of the core DLL extra logic to prevent this.
The thing is, the "clients" call the API, not the Core DLL.
"How" the API accesses the Core DLL is under your full control. Just only expose operation contracts that you wish.
Since you're using C#, I would look at Microsoft's Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries and use FxCop to in-force many of them (latest version here). This won't be all you'll likely need, but it would help put you in the right direction.
Also, take a look at the freely available distillation of Framework Design Guidelines by the same author.
I'm maintaining an application which currently is just a web service (built with WCF) and a database backend. The web service is built in layers with a linq-to-sql data access part with core functionality in an own assembly and on top of that the web service assembly which contains the WCF code. The core assembly also handles all business logic rules (very few actually).
The customer now wants a Web interface for the application instead of just accessing it through other applications which are consuming the web service. I'm quite lost on modern web application design, so I would like some advice on what architecture and frameworks to use for the web application. The web application will be using the same core assembly with business rules and the linq-to-sql data access layer as the web service.
Some concepts I've thought about are:
ASP.NET MVC (or MVC-2)
Webforms
AJAX controls - possibly leting the AJAX controls access the existing web service through JSON.
Are there any more concepts I should look into? Which one is the best for a fresh project?
The development tools are Visual Studio 2008 Team Edition for Developers targeting .NET 3.5. An upgrade to Visual Studio 2010 Premium (or maybe even Ultimate) is possible if it gives any benefits.
Definitely dig into ASP.NET MVC2.
All of our projects are now being developed using ASP.NET MVC2. It's not just highly scalable. It's highly testable as well. Which leads to way better maintainable apps in the long term.
WebForms vs. MVC2 points - (speaking out of experience):
Scalability:
In our company we had a lot of applications using WebForms which then were updated and changed by us as needed by our customers.
I think your customer will be requesting more changes on the application in near future. Making calls to other services, and maybe you'll have to rework parts of the final product to match their wishes.
And with the upcoming Cloud Computing and the Windows Azure platform you'll probably need to keep up with your code.
ASP.NET MVC absolutely supports the concept of being able to scale up your application any time you want.
I remember one of our customers walking up on me asking me for an extension for their app (they have a member management system) and the feature would contain something like a link to export the current view as a csv file so they could do office stuff with it (mostly serial letters).
It wasn't really a big problem setting that feature up. (took around 2 hours including writing tests) - let's go to tests:
Testability:
Using WebForms we didn't really have much interest writing tests because it was a pure pain to do so.
I remember writing some tests to have at least some proofs but let's drop that topic.. (:p)
We had tests for our custom classes but we couldn't really test all the EventHandlers within the WebForms.
Our CodeBase is way cleaner and saver to use thanks to this testable environment. I just check out some of the code, modify it, run all the tests and: Oh, it broke on strange behavior! - Let's fix that again. Earlier, I remember sitting with my co-worker debugging and trying to find those bugs for hours.
With ASP.NET MVC2 we are now lacking tests!
We ask all kinds of people (even the non-Web ones) to provide test-cases we could feed into our TestSuite.
And yeah, there are some AJAX-Controls too:
AJAXability:
You asked about AJAX Controls and in conjunction with ASP.NET MVC I highly recommend you to check out Telerik ASP.NET MVC UI Controls.
If that isn't something for you, we also make extensive use of jQuery and jQuery UI
With ASP.NET MVC and the HTML Views, those libraries aren't just a pleasure to use, they just look amazingly beautiful.
There is no random-html-tag-id-value autogeneration anymore!
But what I like most is: You can finally really re-use your code again.
There is so much more to those frameworks than just that, there is the T4 templating system. Auto-Scaffolding for your ViewModels / DomainModels with the Html.EditorFor() method and of course there is a great and easy way to use the IoC and DI paradigms.
Assuming that you have asked the question with mostly .NET Framework related tags, you'll probably stick with it.
Just to keep the post complete, there are also other frameworks that are just as good (or even better):
Ruby on Rails
Django
CakePHP
And many many more!
There's also DynamicData which may be appropriate if you need simple CRUD access to your data.
The Web Service Software Factory (WSSF) might come in handy in your situation.
This will allow you to define your contracts (XML entity returned (if XML you choose), etc.) while designing the server/client communication using WCF (or standard Web Service communication protocol).
WSSF favors either ASP.NET MVC or ASP.NET MVP. A simple example of the MVP architecture is shown here, plus this article.
As for me, I often come with a hybrid-like architecture using a bit of both MVC and MVP, as both have different strong points which combined together fill each other's improvement points.
I'd also recommend looking into Silverlight.
http://www.silverlight.net/learn/
Just my opinion to use MVC on Client sites and WebForms inside administration pages(site)
I've found an article on this subject by a Microsoft employee, but has anyone implemented a more robust framework for this? Is there a lightweight framework for WinForms that could be ported easily? I'd like to get up to speed fairly quickly and avoid producing a framework/library of my own to handle this when someone smarter has already done this.
I haven't looked at the Mobile Software Factory from the P&P group, but I suspect it's kind of heavy. Is it worth a look?
Edit: I'm not looking for information on the ASP.NET MVC project. I'm asking about the compact framework 'WinForms' implementation, and how to implement MVC with that.
I personally think that the Mobile Software Factory doesn't hold much joy for CF.
We still use one part of it (EventBroker) at work and I'd like to even remove that part if possible (as it doesn't support generic events and you have to cast the arguments into their strong types from EventArgs). A sister project at work used it for part of their UI but had to rip it out due to performance issues (another big project, although that has additional performance issues of it's own as well).
The issue I find with the MVP framework that the P&P lib offers is that Forms and Controls OWN presenters instead of Presenters/Controllers owning Forms (who didn't read "It's just a view" : Pragmatic Programmer?).
This fits beautifully with MS's "Form First" rapid application development mantra but it sucks when you consider how expensive windows handles can be in CE (if you have a lot of them).
We run a very large CF application at work and we've rolled our own MVC framework. It's not hard to roll your own, just make sure you separate everything out into Controllers, Views, Business Objects and Services and have a UIController that controls the interactions between the controllers.
We actually go one step further and re-use forms/controls by using a Controller->View->Layout pattern.
The controller is the same as usual, the view is the object that customises a layout into a particular view and the layout is the actual UserControl. We then swap these in and out of a single Form. This reduces the amount of Windows Controls we use dramatically.
This + initialising all of the forms on start-up means that we eradicate the noticable pause that you get when creating new Windows Controls "on-demand".
Obviously it only really pays to do this kind of thing if you are rolling a large application. We have roughly 20 + different types of View which use in total about 7 different layouts. This hurts our initialisation routine (as we load the forms at start up) by a magnitude of about 10 seconds but psychologically most users are willing to accept such a hit at start up as opposed to noticeable pauses during run-time.
The main issue with the P&P library in my books is that it is a FF -> CF port and due to certain incompatability and performance differences between the two platforms you lose a lot of useful functionality.
Btw, this is by far and away the most comprehensive article i've ever read on MVC/MVP.
For Windows application (desktop or CE) I'd recommend using the Taligent Model-View-Presenter version without the interactions, commands and selections (e.g the controller/presenter performs all the work).
Neither of you (davidg or Kevin Pang) paid attention to the fact that he's interested in WinForms, not Web Forms. He wants a framework that pushes the Model-View-Controller design pattern (davidg, MVC isn't just the name of an ASP.NET framework) in a WinForms project using the .NET Compact Framework. He asked his question just fine.
There's also the OpenNETCF IoC framework (which I don't think existed when this question was asked) which is much lighter, but similar in object model to the P&P's Mobile Software Factory.
#DavidG and #KevenPang
MVC is not limited to a web technology, in fact the original smalltalk MVC was for desktop applications.
It works like this:
View = Client Form
Controller = Wraps up Client Events and marshals between View and Model
Model = Application Data and Business Logic
In pure Smalltalk MVC, the View is not limited to being a form, but can be any representation of Model Data...For example, if we had a Model that represented a spreadsheet, we could have the following views:
SpreadSheet View
Printer Friendly View
Icon View
etc, the Model would be the same, but the View would create a different output object in each case.
All that said, I don't know if such a framework exists for the .NET Compact framework, I just wanted to point out that MVC does not mean WebApp.
Take a look at mFly's Mobile MVC. I've never used it, but it's pitched as a reasonable MVC framework for the CF.
#davidg: "Why would you want MVC on Compact Framework?"
Why not? It's not like it's reserved for web dev, it's a pattern.
Edit: The above posters are correct. I saw MVC and immediately thought of web forms. My apologies. Feel free to disregard this. I'll leave my original message in place just in case anyone who is interested in web forms MVC needs the links. :-)
There are a couple MVC frameworks out there, neither of which are very "lightweight", but MVC is a pretty big shift away from web forms so that is expected:
ASP.NET MVC - This is Microsoft's attempt at an MVC framework. It is still in preview mode so use it at your own discretion, but several people are already using it in their production applications. You will find ample documentation on this with a simple Google search as it is becoming very popular amongst the .NET crowd.
Castle MonoRail - The MonoRail framework is an open-source MVC framework that has been around for quite some time and is in use on several production applications. It is definitely more flushed out than the ASP.NET MVC framework, but considering the amount of effort Microsoft is throwing at their MVC offering, I think will change relatively soon.