I am given a task to move an old ASP.net project from one server to the other. The server on which the project is currently hosted has the 'Published' version and the actual 'source code' along with the solution is completely missing. Is there any way to recover the source code from the published version of the project?
You can use Reflector to decompile the EXEs or DLLs, providing that they have not been obfuscated (in this case you would get a very difficult to understand source code)
Related
There has been a lot of talk about the C# compiler Roslyn on StackOverflow and the internet in general. A lot of people ask what and why with Roslyn, while others ask how to get rid of it.
My question pertains to the latter question. As quoted from Kemal Kefeli from here, but frequently iterated verbatim by dozens more (e.g. another example of iteration), in order to remove Roslyn:
When you create a new web project, two NuGet packages automatically added to your project. If you remove them, your problem should be solved. Package names are: "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" and "Microsoft.Net.Compilers".
This approach, however, does not work if you are using the C# 6 features that Roslyn offers. By removing these two nugget packages, you give up any chance of using these features.
My question is, how do you compiler everything with Roslyn, but avoid having any compiler-at-runtime actions occurring and most importantly, the csc.exe, vbc.exe, and VBCSCompiler.exe from being placed in the final release version (in the Roslyn folder).
I am porting over StackOverflow's Opserver into a piece of software. The software allows users to host embedded web servers and web pages from within it. However, the software is very picky about what it allows to be uploaded and executables, like those found in the Roslyn folder, are not allowed to be uploaded and executed at runtime due to security reasons.
Opserver relies on C# 6 features, because if I remove those two NuGet packages, errors sprout up in compile-generated files. But, if I more simply revert to compile strictly with the C#5.0 compiler, then we see this clearly:
If I leave the NuGet packages present and uncheck allow precompiled site to be updatable when publishing, in order to disallow Roslyn with compiling files at runtime as followed by Rutix's comment from here:
Keep in mind that removing these packages [as told by Kemal Kefeli] will break the use of C# 6 features. This could be solved by unchecking "Allow precompiled site to be updatable" which pre-compiles the views ect.
It still generates the executables and the associated DLLs in the Roslyn folder, however significantly less DLLs. How can I possibly remove the Roslyn dependency at runtime and therefore the executables from the outputted version and strictly compile everything at compile-time?
In fully precompiled ASP.NET project ("allow precompiled site to be updatable" disabled) there is no need for compiler to be deployed with app IMHO.
I'm using Roslyn in my .NET 4.6 ASP.NET app (mix of Web Forms and MVC) and precompiled app works just fine after removing Roslyn folder\files from published site...
UPDATE: After a while a found only place where absence of Roslyn in deployment package is the problem a that's accessing ASMX (old style ASP.NET SOAP web service) in browser - "help" page for ASMX is apparently build at runtime even for fully precompiled ASP.NET application and it throws exception (although WS itself runs OK)
I've inherited a legacy code base that doesn't currently compile and has no project or solution file (there are multiple repositories including winforms and asp.net).
I'm not certain what .net version the original code was written in, nor what the project template was, although I know some are web forms.
I'm re-creating new solution and project files to import the code into, but need to find some of the default dll's included in old Visual Studio project templates (e.g. webforms).
Any ideas where I might find this information?
Anyone know an MSDN link with this on it?
P.S. I don't have access to the production code, although it is running in production.
Am I doing this right? I've got many, many separate ASP.NET webforms projects which reference the same main library which contains many tool methods. When I change something in that library, I don't know of a way to make sure that these projects get the updated version of the library. Does auto-refresh detect changes in references even if you don't open the project in Visual Studio? Or does IIS know when a reference has changed and will recompile the project?
Assuming the DLL file is binary compatible (changing an existing method signature is the easiest way to break compatibility) all it comes down is that the newest DLL is in the \bin\ folder. If the site is running it would need to be restarted to pick up the DLL being replaced.
If this is a project reference in your solution, building just does all of this for you.
If this project is outside of your solution, you really should look into using Nuget to distribute this shared project. Even if you only distribute it to yourself. You do not need to host the package publicly on nuget.org
I'm compiling ASP.NET code for the first time ever and I'm stumped.
I downloaded MINGW-Get and just finished installing it. The client gave me the source code and I found a file called RSConfig.exe.
So I assumed that was the config file, ran it, and then tried "make" but got the error
No targets specified and no makefile found. Stop
Any idea what I'm supposed to do? I don't see anything that would resemble a makefile in the source code.
Thanks in advance!
Do yourself a favour and install Visual Studio Express:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express
It makes development easier and fast
It sounds like you might want to get familiar with the background concepts around asp.net and it's defacto development environment Visual Studio (there are many versions of visual studio).
As Andrei recommends, using Visual Studio Express is a good free way of getting started. The version most suited for web development is Visual Web Developer Express.
Attempting to compile .net code from a toolset such as MinGW isn't a typical route for using asp.net, however I've not used MinGW before and not sure it's possible to compile .net code from it.... Although it is perfectly possible to compile .net code from the command line (using the .net framework sdk) , I certainly wouldn't recommend it if you are getting started.
I'm going to make a guess that it is an ASP.net web forms project, it being the most prolific asp.net project type at the moment.
This official asp.net site http://www.asp.net/web-forms will guide you through what web forms are and how to get the development environment setup. Having this sort of background will aid you in solving your particular situation.
I have an ASP.NET 2.0 legacy website with me, in which I have to fix two bugs in the website.
The problem is that we ( me and client ) do not have the source code for this website.
All we have is the FTP where the compiled and hosted version of the website resides.
Now, we are pretty sure that the developer has not intentionally done anything to obfuscate that compiled code with any other third party tools. He have just used the standard Visual Studio compiler.
My questions are
Is it possible to get the source code from the compiled version?
How can I get the source code from this compiled version?
What other options do I have?
Will .NET reflector be handy to extract the code?
Yes, .Net Reflector should be all you need to decompile the code (without comments, anyway).
Try opening the DLL files from the bin directory inside .Net Reflector and see if you can make sense of it.
EDIT: It appears that after investigating ILSpy, which Adrian Iftode mentioned, there is an open source plugin for .Net Reflector called Reflexil that does what you need - modifying compiled DLLs. That would be well worth a look at!