Extract aspx pages from precompiled asp.net web site - asp.net

Is it in any way possible to go from a pre-compiled asp.net site and back to something resembling the original code (with markup that I can update in aspx and ascx files). I have lost the original code and is left with the precompiled version of the pages. It is possible to disassemble the dlls but the code is very hard to figure out and I get many different error messages, when I try to update and rebuild the dlls that contains the precompiled aspx and ascx pages.

Reflector is your friend, or ildasm.exe if you know how to read MSIL. And next time use a VCS to put this code under source control to avoid uncomfortable situations like this.

Related

beginners query about asp.net website management

I recently started managing a asp.net website. earlier my employee had simple HTML and one php website and I can easily work with both of them and can do medium level of customization like add/edit things. But now i have asp.net website and its killing me.
All the files are precompiled but I have source code. Please tell me how to add edit content etc. Consider me as a student with required knowledge of HTML, php and css.
For example I was told to add a table in a page, I had html code for same but did not know how to do it. I tried adding it in HTML file and aspx file but no use. Than I add it in files in bin folder and website started giving error about precompile index file first.
Now when you know my understanding about asp.net is nil, please, guide me to save myself from embarrassment I may face. Although its not my job M into marketing but during interview I said that I can do it all w/o knowing they have asp.net for me. Also let me know the tools I require like visual studio, iis etc.
This is why ASP.NET works best for complicated websites with a well-defined build/deploy process and not simple websites that need updating regularly.
You should be able to add and edit static content in the *.master, *.aspx and *.ascx files without any problems - the ASP.NET runtime will recompile those files on the server, so there is no need for the source files - unless the website was compiled with "stub" *.aspx files (that's when the files have a single line that looks like <%# Page Inherits="MyAssembly.SomePage" %>).
You said you tried this already, but that it was of "no use". Can you explain what happened afterwards? Did you get any error messages?
The bin folder is where you put the DLL files from the project after it has been built (the build process includes compilation). Can you please show us the entire "precompile index file first" error message you received? The descriptions you've given us are too vague to help you with.
If your ASP.NET site does not have any custom logic beyond a simple "Contact Us" email form, then I strongly suggest you convert it back to a static HTML or PHP website, if only to save everyone's sanity.
You don't really have a question here, and there's not going to be a substitute for "cracking the book", watching some on-line tutorials, etc. I appreciate you're in a tough spot, but just willy-nilly adding stuff to an .aspx file will cause you serious grief in the long run.
Do a Bing search for PHP an ASP.NET and you'll find some relevant resources that leverage skills you already do have to bring you into the ASP.NET mindset, explain the development and deployment model, and describe the page lifecycle model.
Here are a few:
ASP.NET for PHP Developers
Get Started with ASP.NET and ASP.NET MVC
ASP.NET for PHP Developers: Introduction to ASP.NET

Asp.Net/Sitecore embedded ascx resources not picking up changes

I'm not sure if this is a Sitecore 6 or Asp.net problem.
I have an assembly made up entirely of ascx user controls in which all of the necessary files are embedded resources (ascx, javascript, etc). I have been using the user controls in this assembly in a Sitecore web site for a few months.
Recently I tried to make changes to some of the user controls. I'm sure I made changes to the user controls in the past and it worked fine. But now when I make any changes to the ascx files they don't get picked up in the website. Changes to other files, including the code behind and javascript files are getting picked up. It appears only to be the ascx files that have a problem. It continues to use the old versions of the ascx files, from where I have no idea.
I know it's using the latest version of my assembly because I've stepped through the code behind, and used Fusion to check where the assemblies are loaded from. I've tried deleting all of the files in the Asp.Net cache. I've looked at the ascx files inside the assembly using a decompiler and it does have all of the changes I made. I turned off all caching in Sitecore just to see if that would fix it, but it didn't. I can't think of anything else to check. Any ideas?
Seems there is a new flag in web.config compilation settings called optimizeCompilations that is supposed to make things compile faster. Someone set this to true and that caused changes to user controls in other assemblies to not get compiled

If code behind not used, is aspx source code exposed to website visitors?

I've read through some of the questions here and my understanding is that this is true. Could someone confirm that visitors to an ASP.NET website can actually download the aspx files in their original format? Just like with the css files, etc. Thanks.
Clarification: Please be patient with me. I am newbie and just want to make sure I understand. I know that using Dreamweaver, a person can just download almost all the source files from a website. At least that what could be done some years ago with many websites. He would just change a few text contents and have a similar website like the original with all the original design, images, etc.
So if he can do the same with an asp.net site: downloading all the files, he can look at the aspx file and see what the code does. I am not talking about him executing the page and do the view source command. This file would naturally be processed by the server and doesn't expose source code.
This is one of the reasons why code behind is recommended because the code can be compiled and the source is not uploaded to the site. Only the dll is uploaded and minimum logic is exposed through the aspx file.
No, they can't. The ASPX page contains server-side code that is executed, well, by the server, and ends up containing plain HTML that the client browser can understand.
When IIS receives a GET request for an ASPX page, the ASP.NET handler kicks in and returns the processed HTML. So unless IIS is misconfigured, that is not possible.
No. Visitors cannot see your business logic.
If that were the case the markup asp:TextBox wont get rendered as input type='text'
Also, if that were the case we would be seeing code snippets of sites written using scripting languages like PHP or Classic ASP
in newbie's term:
No, the server won't give you ASPX and code behind files, these are files that don't mean anything to the end-user/visitor/browsers. These codes are processed on the server, and what you get is only a bunch of HTML code, javascripts, css, images, etc. which browsers can render.
If you try to "download" (by accessing them through your browser) .ASPX, .CS, and WEB.CONFIG files to see the actual source code, well you simply can't.

Visual Studio 2008 losing intellisense for ASCX with CodeBehind (but works for CodeFile)?

I have the following definition at the top of my .ASCX file:
<%# Control Language="C#" AutoEventWireup="true" CodeBehind="ArticleView.aspx.cs" Inherits="MyNameSpace.ArticleView" %>
In that control I make use of <%= %> blocks to refer to members that I've declared in the code-behind file. If I compile and deploy the control, it works fine. But in Visual Studio I get a lot of design-time errors, "{some variable} does not exist in the current context." And Intellisense breaks too: it works for members of UserControl, but can't find my own declared members. There are other issues as well. In general, everything points to the fact that the ASP.articleview_ascx class getting generated is somehow not inheriting from the MyNameSpace.ArticleView class.
I've found that if I switch the CodeBehind attribute to "CodeFile":
<%# Control Language="C#" AutoEventWireup="true" CodeFile="ArticleView.aspx.cs" Inherits="MyNameSpace.ArticleView" %>
suddenly Intellisense works and all the design-time errors disappear. But I don't want to do runtime compilation, or deploy my .ASCX.CS files - so I can't use CodeFile.
I've checked the simple stuff, like making sure that my CodeBehind filename is correct & the Inherits class has the proper namespace, etc. (And since it works properly after changing the attribute to CodeFile, those must be pointing at the right place....) But what am I missing? Why can't it handle the CodeBehind attribute?
Thanks,
Steve
Update: from a thread below - basic question was, why not just use CodeFile? Answer: when I try to deploy using CodeFile= in my files, after deploying I receive the following stack trace (presented in its entirety):
/_layouts/Pages/ViewPage.aspx.cs' does not exist. at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) at System.Web.UI.TemplateParser.ProcessCodeFile(VirtualPath codeFileVirtualPath) at System.Web.UI.TemplateParser.ProcessMainDirectiveAttribute(String deviceName, String name, String value, IDictionary parseData)
(This is from a request to /_layouts/Pages/ViewPage.aspx. ViewPage is the page that has several other controls including the ArticleView mentioned in my original example. It just happens to be the first file that fails - if I go back to CodeBehind= in ViewPage, then included ASCX with CodeFile= will fail in the same way.) This seems to be the page compiler complaining because the inherited codebehind class can't be found in any loaded DLL, so it expects there must be a CS file to do on-demand compilation.
The issue here is that I don't want to deploy CS files, just ASPX/ASCX. Having read through many articles like this great one I'm aware of the various new models of deployment, although I've never used anything but a Web Application Project (converted forward from VS2003, we were late adopters of 2005 & the WAP model had already been added by the time we switched up from 2003.) Over many VS2005/8 projects, I've never had a problem with CodeBehind=, until this Intellisense issue showed up... though it doesn't help that in this case I'm deploying to SharePoint, which introduces a whole new level of complexity.
Since I've not deployed using CodeFile before, it's very likely that I'm missing some option I'm supposed to set in VS when building, in order to force a pre-compile. I just need to be able to deploy, as I do today, as a set of ASPX/ASCX with a single codebehind DLL. And that's working today with CodeBehind= ... it just has the originally mentioned Intellisense problem, which is really what I want to fix :)
Will post more as I identify what files might be relevant to the question...
Have you checked the Build Action on your project files? I have duplicated your issue by setting the Build Action on ArticleView.ascx.designer.cs to None. I can also compile when using CodeFile, etc..., I'm 99% sure that's your problem.
You are missing the [your-file].ascx.designer.cs file, which links your controls to your codebehind.
Just like CitizenBane suggestions, you need to right-click the file (or folders, or entire web project) and select "Convert to Application". Visual Studio will examine your ascx/aspx files for the server controls, and generate that designer file for you.
I actually ran into this myself, on a far larger scale... C#: How to convert a Website project to a Web Project
Check the answer.
This has happened to me before. Try right clicking the ascx/aspx and click on "Convert to Web Application". You may just be missing the generated controls. If you don't see it in the context menu, delete the designer generated file first.
CodeBehind is deprecated in .NET 2.0. I believe that only <= 1.1 uses "CodeBehind". Now it is "CodeFile" as you say.
Why do you not want to compile your code? If you compile you don't have to deploy your .cs files...
Why do you have the code behind for your ascx control as an aspx named page code behind?
A UserControl (ascx) usually has a codebehind of
CodeBehind="ArticleView.ascx.cs"
instead of what you have listed
CodeBehind="ArticleView.aspx.cs"
Notice the aspx instead of the ascx for a User Control.
That could be your problem... a simple typo or a copy and paste error. Couple possibilities come to mind:
Maybe you have the ascx control (User Control) specified above using a code behind file that is inheriting from System.Web.UI.Page instead of System.Web.UI.UserControl (that could be causing the Visual Studio errors).
You have the UserControl pointed at the code behind for a same name aspx page. Similar problem as #1 which would cause Visual Studio to get all confused.
Your files are name ArticleView.ascx and ArticleView.aspx.cs. This might confuse Visual Studio since I believe VS might expects a particular naming convention.
For a User Control (ascx) your files should be named:
ArticleView.ascx (CodeBehind="ArticleView.ascx.cs" Inherits="[NAMESPACE].ArticleView")
ArticleView.ascx.cs (inherits from System.Web.UI.UserControl)
ArticleView.ascx.designer.cs
For a Web From (aspx) your files should be named:
ArticlePage.aspx (CodeBehind="ArticlePage.aspx.cs" Inherits="[NAMESPACE].ArticlePage")
ArticlePage.aspx.cs (inherits from System.Web.UI.Page)
ArticlePage.aspx.designer.cs
This just happened to me in VS2010 after upgrading a web application project to .net 4.0.
The answer was to make sure you have targetFramework="4.0" set on the system.web/compilation section in web.config
i.e.
<system.web>
<compilation debug="true" targetFramework="4.0">
</system.web>

How to consolidate ASP.NET master pages across applications?

First shot at throwing a question on these boards so hopefully I can get some help, here goes:
I am working to start up the .NET practice at my client. We have 5 small scale .NET applications in place currently with a few them of them live into production. They're mostly small reporting pieces with some data entry/business logic functionality. Each of these applications is currently using the identical master pages.
What I mean is that there is a copy of the same master page in each application. They are all basic website->WCF->BL->DB tiered applications. So I have 4 copies of the same master page that I have to change when I make a change to it.
The client DOES NOT want to consolidate all of these into a single solution. They like the separation of applications across sites. I just don't want to continue dealing with the hassle of multiple updates for common elements (which there will be many more of across these applications).
The code is all stored in team foundation server. We also do NOT want to compile the master page into a .dll and deploy it.
Can anyone please make some suggestions as to how I can maintain a single copy of these common files (master, .css, etc) across my multiple applications.
thanks in advance
You might want to look at Sharing Master Pages in Visual Studio.
If that is no help then you could try using Build Events in Visual Studio. I would pick one of the projects to be my "Main Project" and only edit the master page from that project. When you build the project it would run a command that would copy that master page(if it had changed) to your set locations.
The client DOES NOT want to
consolidate all of these into a single
solution. They like the separation of
applications across sites. I just dont
want to continue dealing with the
hassle of multiple updates for common
elements (which there will be many
more of across these applications).
The code is all stored in team
foundation server. We also do NOT want
to compile the master page into a dll
and deploy it.
You eliminated the only two real options there. What all is in the master page? Would it be possible to extract the HTML UI elements to a single template or series of template HTML files and import those dynamically into the master page? You could then relocate the common HTML to an arbitrary URL and have the master page for each application pull it in dynamically.
Edit: I lied. You could also use a VirtualPathProvider like Sharepoint does to store the master page in a database or some other directory, but beware that VirtualPathProviders do not work in MediumTrust environments.
See:
http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.aspx
If you are using Web Applications (compiled into a dll) rather than Web Sites you can do the following:
Right click on the folder you want to store the master page in
Select "Add Existing Item..."
Browse to the master page on the file system, and select both the .master and the .master.cs files.
Then, rather than clicking on the "Add" button, click on the little down arrow to the right of Add, this will bring up a little menu with the options: "Add" and "Add As Link"
Select "Add As Link" this will reference the file in your project, while leaving it in the original location in your dev environment - this allows you to edit it in either application, while keeping it up to date in the other applications.
Obviously if you edit the code behind, you'll need to re-compile the other projects before you deploy the changes to those sites.
This isn't available in web site projects as they rely on the file structure to work out what is in the project.
EDIT: Missed the css part. Obviously you won't be able to serve those files, so this should only work for the master page.
Don't know your scenario, so
IF you can control the DNS / virtual directories to the applications you could use a format like this:
c:\inetpub\wwwroot\Application1
c:\inetpub\wwwroot\Application2
c:\inetpub\wwwroot\Application3
c:\inetpub\wwwroot\Application4
c:\inetpub\wwwroot\Application5
and have your Master page at c:\inetpub\wwwroot\master.Master,
c:\inetpub\wwwroot\master.Master.cs,
c:\inetpub\wwwroot\master.Master.cs.designer
Then you could reference the single copy of the master page from /../master.Master. I gave this a quick shot with a precompiled master page to make sure I could reach back beyond my root. You might have to give it a shot to see.
We use our source control to create links to the shared files in all the places that we need it. So if you edit in one place, you just need to do a get latest and it will appear in the other places you have linked it.
I ended up going with the VPP route. I created a virtual path provider and built my master page into a DLL and this is working. Now I have a massive problem though in that a Content page whos master page is late bound through the codebehind throws validation/formatting hissy fits because it thinks its should be a stand along page. my CNTRL + K, CNTRL + D has broken on every page where I'm now sharing my master page. This is extremely frustring for me and the team

Resources