Writing a ASP.NET website, we have a lot of legacy components we need to rely on.
My view is that because we are MTA (Multi Threaded Apartment) in ASP.NET, if we use a STA component then the requests will queue. So even if we use a .NET component which is MTA, if IT relies on an old STA component, this will still queue. Am I right so far?
Anyway, my real question is - By examining a .DLL ONLY, can I find out which threading model it was built under?
Thanks
Duncan
ActiveX and COM are basically the same thing -- they must both be registered in order to be used. Threading models (as far as I know) only apply to COM objects, not .NET objects, so unless you're doing COM interop you shouldn't need to care about threading models.
Related
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.
I've written a class in VB.Net that is consumed in an ASP.NET Web Application running IIS7. I use .NET Framework 4.0. The class performs a REST request to an online and retrieves an XML response containing strongly typed data.
This class also performs caching using an SQL Server database. The class is compiled to a .DLL and referenced by the Web Application. It works excellent and now I need to know how to make the class thread-safe.
I have no experience with making code 'thread-safe'. I don't know where to begin in determining whether or not it is thread-safe. Am assuming, because I didn't pay attention to this during development, that it is NOT thread-safe and that since it the web application will be used by many users at the same time that it must be payed attention to.
Can anyone point me on how to test for thread-safety? Are there any resources online that that will give me some ideas? Are there any rules of thumb that will tip me off as to where my main concerns are?
The easiest possible thing you can look out for is the use of "static" (C#) or "Shared" (VB.NET) variables. If these variables can be modified throughout the lifetime of the application you will likely run into threading issues which can really often result in "random looking" problems.
I would also be concerned about how you are doing the caching in your database as multiple .NET threads hitting SQL (for the cache) could cause issues as well depending on how its designed.
Bottom line is you are likely going to need to learn more about threading if you want to be sure this is going to not have issues. Probably the best book I have ever read in terms of simple to very complex C# topics is C# 4.0 In a Nutshell I would take a look at that book especially the threading chapters. (Seriously read the whole thing though) If you get that read through and have a good understanding of the concepts mentioned you should be fine.
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.
How do I access a COM component from an ASP.NET page. I added reference to my ASP.NET project.
The actual dll I got from the 3rd party is ePadIIu.dll but when I added it to the ASP.NET project it shows as ePadIIu.interop.
I want to access all the methods and properties in the component.
The sample I received from the 3rd party software uses vbscript to access all the methods.
How do I use those methods in the code behind from default.aspx.vb.
When you added the reference to the COM component from your ASP.NET project, Visual Studio ran it through tblimp (type library import utility) to generate an interop assembly for use with .NET. By convention, it named it ePadIIu.interop.dll.
If you view this reference in the Object Browser, you should be able to determine the namespace you will need to reference, as well as any of the classes, properties and methods exposed.
Your using statement at the top of your *.cs might look something like this:
using ePadIIu;
Caution - Slippery When Wet
VB COM components are notorious for being compiled using a Single Threaded Apartment (STA) - though not always the case (if I remember correctly). If ePadIIu happens to be a STA COM component you might experience:
Slower performance
Possible memory leak due to blocked finalizer (not trying to be all doom and gloom, just seems to happen more often than not)
References discussing the problem:
COM Interoperability in the .NET Framework
Running ASMX services on STA Threads
Developing High Performance ASP.NET Websites
ASP.NET Hang and OutOfMemoryException caused by STA Components
Good Luck!
Z