I have an existing application that is closed-source and ships its own version of Mono 3.5. I want to change the behavior of the application; specifically, I want to swap out a built-in class with a new one.
Normally, one goes about this with Mono.Cecil. However, in my case the application assembly is loaded from a readonly volume which makes modifying the assembly itself very very tricky (it involves hardware hacks to produce a new volume). I can, however, get it to load an arbitrary DLL via an officially-supported mechanism, which I could in theory use to modify the assembly at runtime.
There are numerous resources for achieving runtime code injection / function hooking via the .NET Framework, but they all fail under Mono. Approaches I've seen include:
System.Reflection.Emit.MethodRental.SwapMethodBody - not implemented in Mono
This CodeProject sample - uses Microsoft internals
Microsoft Fakes - more Microsoft internals
This MSDN blog post - Even more Microsoft internals
See related questions:
Can Mono.Cecil modify code already loaded in the AppDomain?
Can I redirect .NET method calls to a new method at runtime?
Dynamically replace the contents of a C# method?
I am aware that this is a pretty terrible plan. However since I don't have the sourcecode and modifying the assembly on disk is even more terrible than doing some kind of dirty runtime hack, this is the best alternative I've generated so far.
Related
tl;dr Does strongly typed resource code generation work with normal (non-embedded) resources in App_LocalResources?
If not then why, and does the alternative of using embedded resources in satellite assemblies work with implicit localization?
The rest of this post just explains where I currently am in solving these questions, feel free to ignore it if you know the answers.
When using implicit localization (meta:resourceKey="Foo" syntax), I understand that one would need to write their own resource provider if one wants to embed the resources in satellite assemblies. The reason would be that ASP.NET always uses the default provider for these, and that this provider expects resx files in App_LocalResources that can be retrieved at runtime. Also see this question, which has no answer at the time of this writing.
If that assumption is correct, then it doesn't seem possible to use strongly typed generated classes (using ResXFileCodeGenerator) without writing such a provider (which we'd like to avoid doing), as enabling code generation requires the use of embedded resources.
Because the use of generated types appears to work perfectly fine for global resources, I want to question that second assumption:
If I can generate strongly typed classes for global resources (in App_GlobalResources using GlobalResourceProxyGenerator) without embedding them in a satellite assembly (Build Action set to Content as opposed to Embedded), then why can't I do the same for local resources? Why can't the generated code find and use the resx files in App_LocalResources?
Note that the exception thrown when attempting to do this is a System.Resources.MissingManifestResourceException containing the following message:
Could not find any resources appropriate for the specified culture or
the neutral culture. Make sure
"PROJECT.App_LocalResources.PAGE.aspx.resources" was
correctly embedded or linked into assembly "PROJECT" at
compile time, or that all the satellite assemblies required are
loadable and fully signed.
I know that this message is misleading, as it clearly looks up satellite assemblies instead of trying the resx files (or whatever they're compiled to by the runtime, App_LocalResources.dll I guess).
If there is a good reason why this is not allowed (and we are thus forced to use embedded resources in satellite assemblies), is there a good implementation of a resource provider that can look up resources in satellite assemblies when doing implicit localization? Surely somebody has tried to do this before, and it doesn't sound like the application developer's job to tackle this kind of plumbing problem.
As a sub-question to the previous one, I also assume that when using embedded resources in satellite assemblies, one wouldn't put the resx files in the App_* directories, as these are special directories used by the runtime. Indeed, the resx files aren't even deployed, so the directories would be empty. Is that correct, and are there what would pass as best practices regarding this?
I suppose another way of formulating the question is: Can I make ResXFileCodeGenerator behave like GlobalResourceProxyGenerator when it comes to generating code that can load assemblies compiled by the runtime, as opposed to satellite assemblies compiled at build time?
Embedded resources can co-exist with ASP.NET Resource provider resources that live in the App_LocalResources/App_GlobalResources folder. But all the intrinsic WebForms localization features only work with the resources that are fed by the ASP.NET Resource Provider, which means the resources by default come out of the App_ folders only - not from embedded resources.
Embedded strongly typed resources do not use the ASP.NET Resource Provider - they use a stock .NET Resource Manager and when you use them you lose some of the optimizations that the ASP.NET ResourceProvider system uses vis a vis caching and loading of resources. It's more efficient in the ASP.NET scenario.
As you correctly point out it's possible to do this by creating a custom resource provider that reads embedded resources (or resources from another source such as a database), but you have to create this resource provider and hook it up. I wrote about this in an article some time ago (using a SQL database provider): http://www.west-wind.com/presentations/wwDbResourceProvider/
I wouldn't recommend mixing App_ folder resources from the Resource Provider with strongly typed resources because you'll end up with two different sets of resources loaded using different mechanisms. It works and can be done but it's just not very inconsistent. Pick one approach or the other. For Web Forms the resource provider model works better simply because it's the only way you'll be able to use implicit resources.
Note that ASP.NET MVC doesn't use the ASP.NET Resource Provider typically (although it could) and rather relies on strongly typed resources embedded into the code. If your WebForms code is mainly script based then using embedded resources might work well, but if you need to bind control properties the Resource Provider is the only way to go.
I'm having to update one of our ancient Intranet applications that was written in Classic ASP and utilizes an in-house COM+ Service. I cannot find the source code to this object anywhere and it was not documented by the developer.
I can view the methods available in the Service through Start -> Administrative Tools -> Component Services but can't for the life of me figure out how to look inside the methods to see what they're doing.
Is there anyway to decompile these COM+ Services, or otherwise see what their methods do, or am I doomed to pure observation of the old application and try my best to mimic the behavior and data?
Note: I exported the service from the old server, installed in on my dev box, added the reference to a VS2010 project, and tried to discern these methods using the Object Explorer. Nothing...
COM services include type descriptions of what methods exist on the COM classes and their parameters so that automation controllers can figure out how to pass parameters to the COM methods.
Beyond that, though, there is nothing to indicate what the COM classes do internally other than the native x86 machine code itself. You can try using an x86 disassembler on the DLL, but unless you are already familiar with x86 machine code instructions, this won't be a lot of help.
Compiling source code down to native machine code throws away an enormous amount of information. Variable names, internal function names, none of that is needed for the CPU to execute instructions and perform the operations indicated by the original source code. It is virtually impossible for disassemblers to reconstitute these names that would be helpful clues as to what the code is intended to do. A disassembler can sometimes help figure out core logic, but it will require a lot of careful analysis and effort by a person to even scratch the surface. It's like trying to understand the forest by looking at individual blades of grass.
Is it possible to include a .net 3.5 framework DLL in classic asp?
You will need to expose this .NET assembly as a COM object. This could be done using the regasm.exe utility. For this the types that you need to use or the entire assembly must be decorated with the ComVisible attribute.
Then consume the COM object from classic ASP as you would with any normal COM object.
Yes, it's called creating a COM-Callable Wrapper.
Here is the MSDN Documentation
The link that pops up for the Code Project article in Google is, surprisingly, not the better one. You'll want to check out this one: Exposing .NET Components to COM It's the best. Complete step-by-step tutorial.
It's worth noting that in a former life I had to develop and support a .NET application which was exposed to some COM-based integrations - and simply slapping ComVisible on my classes was putting me in a world of hurt. Pay attention to the author's explanation of the Interface Types in that article... that article is a gem.
Excerpt:
Previously I was using AutoDual,
however Heath Stewart[^] pointed out
this was not the best method to use as
it can create version-related problems
in the long run. After reading a
little more I changed the code to use
ClassInterfaceType.None which forces
our class to gain access only through
our interface. This keeps everything
viable during changes to the class in
the future.
Are there any ways to encrypted a project in ASP.NET, so my customers can not change change the function where it checks the license code?
No, it is not possible.
You can implement certain things that make it more difficult for customers to reverse or alter your program, in order such that it becomes cost-prohibitive to attempt such reversing or altering. But you cannot prevent them, if they are sufficiently determined, from reversing or altering your program.
Take a look at Eziriz's .NET Reactor. It's pretty good at protection. From ther site:
.NET Reactor prevents decompilation by
a variety of methods which convert
your .NET assemblies into processes
which no existing tool can decompile (
and which are also very likely to
prevent decompilation by any future
tool). .NET Reactor builds a native
code wall between potential hackers
and your .NET assemblies by producing
a file which cannot be understood
directly as CIL. Because the CIL in
your assembly is emitted intact only
at run time or design time (in a form
in which the source is completely
inaccessible), no tool is capable of
decompiling .NET Reactor protected
assemblies.
The native code wall created by .NET
Reactor between the hacker and your
source includes industry leading
NecroBit technology, which is
exclusive to .NET Reactor. .NET
Reactor's protection has never been
broken since the first release in
2004. These technologies make reconstruction of your source code
more difficult by so many orders of
magnitude that NecroBit is by far the
most effective protection you can use
for .NET assemblies.
Not if the customers are persistent and have even a modicum of skill. Obfuscation can only get you so far. Any .Net assembly can be decompiled.
See here for info:
https://web.archive.org/web/20210802164013/https://aspnet.4guysfromrolla.com/articles/080404-1.aspx
Added
Also, see this previous question:
.NET obfuscation tools/strategy
use Dotfuscator Community Edition that ships with VS. Also put checksum function to check if your EXE is changed or not.
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).