As seems my life at present, I have inherited yet another project that needs changing.
However this code has been precompiled (and guess what...)
I have what puports to be some of the source code, and a set of assemblies form the temp folder. However the project is moaning about missing some user controls and a master page in a sub directory.
I cannot see these anywhere in the assembiles I have, and they are not in the code I took from the website. So, where do I find the UI part of precompiled masterpages and user controls ?
You can use an IL decompiler like ilspy or reflector on the compiled website DLL and retrieve the original source code from it.
This is likely to take quite a bit of time and effort, but you should be able to reconstruct most of the missing source this way (though you will probably not have the correct variable names or exactly the same code and definitely no comments).
Related
I had to change some code that was created by another person in VS2008, I converted it to the VS2010 version and was working just fine until the moment I needed to change a master page file. The moment I opened it, it gave me a lot of "does not exist in the current context" errors from the code behind showing that the code behind file could not find some of the controls declared in the master page file.
So, the code that gets errors is like this:
<li class='<asp:Literal ID="litLIClass_Test1" runat="server"/>'>stuff</li>
As you can see, the <li> CSS class is being generated inside that ASP literal, but it seems that the ASP literal doesn't get initialized.
However, it seemed to be working before, and I am trying to understand why it started giving me errors when I opened the page code for the first time in VS2010. Is there a particular setting that enables this kind of nesting? Could there be different settings in VS2008/2010?
In my experience, this is usually a Namespace not matching issue.
A few things to try:
I list this as #1 because it's the quickest, Make sure your local
web server is also turned off, Restart Visual Studio, Recompile (it
works sometimes in my experience). Make sure that the namespace in
your code behind file matches the namespace in your page (if it's
WebForms). I assume this also includes the master page but I don't
know, I do know that you can get this error when the ASPX and the
code behind namespaces are off.
If it's a code behind scenario, make sure the form is inherited properly.
Make sure you're not missing a reference you need. This is a common
cause of the error, especially when upgrading. Your code files
maybe identical but your web.config or what is referenced by default
might have changed.
I've read that this can be caused by two forms pointing to the same
code file, but I've never actually experienced that (nor do I do
that).
References:
http://msdn.microsoft.com/en-us/library/t8zbaa6f.aspx
http://geekswithblogs.net/mikehuguet/archive/2011/01/03/143332.aspx
(I had more reference links to post but I can't because I don't have the reputation yet). ;)
I have been asked to support a legacy app and I can't get access to the code behind files. I need to add a new feature that gets a list of items from the database on page_load, what way would adding an "in-page" page_load affect the compiled page_load?
What would be the best approach to take with this?
Since you mentioned that the legacy app has a Page_Load I assume it's .NET. This means that you should be able to decompile it using Reflector from Redgate to get the original source.
The source will likely be much less "pretty" than it was originally, but you should be able to get editable, compilable source out of it.
As for the question of an in-page page load and a compiled page load - You can try it... But I doubt it will work. You're really better off trying to get the source if you can.
There is a pattern in ASP.NET - whenever there is a piece of markup that generates code (like the .aspx/.ascx files in WebForms or .cshtml files in MVC3), these files are dynamically compiled at runtime. aspnet_compiler will produce another assembly for them, which references your code-behind assembly.
This approach seems awkward to me and I don't understand why it hasn't been discontinued already. A much better approach (in my opinion) is like in Winforms or resource files - you have your .whatever file, and then there is .whatever.desginer.cs file. This designer file is created at runtime as you type. When you compile, the compiler doesn't care about your .whatever file, it just takes the .whatever.designer.cs file and produces a single solid assembly.
This provides several benefits:
You can inherit your forms from each other, similar to windows forms;
You can always see the code that is being generated, possibly adjusting your markup to generate better code;
You can easily instantiate strongly typed instances of your forms;
The only benefit I can see from dynamic compilation is that
You can change the markup file anytime and don't need to recompile the app.
To be honest, I've often wanted for one of the first three benefits, but never for the last one. Recompiling the app to see your changes isn't that big of a deal. Especially since you have to do it anyway when working with code-behind, where the most of your time will be. And when you deliver your app to the client, you deliver it as a monolithic, precompiled block. When you update, you update everything, not just individual .aspx files - there's no point to.
So... why is it like this? What am I missing?
It sounds like you are referring to an ASP.Net Website. An ASP.Net Web Application is like an ASP.Net Website, but uses .designer.cs files and produces a single assembly.
See ASP.NET Web Site or ASP.NET Web Application?.
One thought that comes to mind is that the primary difference between winforms and webforms has to do with the common development model.
Namely, there is a whole class of developers and designers who work strictly in html/css/javascript. They use a host of tools ranging from notepad on up to competing development products to build these pages.
Further, in the case of WinForms, MS has complete and total control of what can make up a form. Any controls that can be dropped on it have to descend from their specified code.
However, with HTML they don't have this same level of control. Spec changes occur out of sync with VS releases, additional features are added that are browser specific, etc. In short, they can't guarantee that a particular element in the HTML file is a valid element at all. All they can hope for is that whatever is sent was done so on purpose and that the browser knows how to deal with it.
Now they have tried to implement a model that provides visual inheritance. It's called "master pages". However, I believe the only tools that properly work with master pages are VS and Expression. Getting the other vendors to go down this path would be nearly impossible. Also, they've added the concept of "nested master pages" such that you can get multiple levels of inheritance out of them.
The code behind model helps to implement non-visual inheritance allowing people to completely revamp page processing (hence how MVCx works).
Which leaves us with the parts that MS does know about. Obviously they do have a .designer file which backs the .aspx pages. This designer file maintains the server control list that is accessible by the code behind. You could add runat="server" to every regular element in an html page (excluding artifacts like css) but this would increase the amount of processing required for the page.
To sum up, I think they've picked the best model they could for web development given the lack of control they have over how the web works. Other vendors have tried similar paths (e.g. Adobe Contribute, previously by Macromedia). I believe some of those even predate MS's model.
I'm developing second language support for the site. So I made duplicate .ascx and .aspx files for existing ascx.cs and aspx.cs
Most of the time everything works fine.. but suddenly I'm getting:
Type 'ctrl_xxx' exists both in 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\d072cc72\b9d5698b\App_Web_xdmblegv.dll', and in 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\d072cc72\b9d5698b\App_Web_gkptrzo2.dll' (translated from russian)
ctrl_xxx ctrl = (ctrl_xxx) LoadControl("xxx.ascx");
I have few such strings of code... and same error occurs with one of them. But WITHOUT any changes from me with those files. To fix thaat bug for some time I need to delete solution and website folder and reget them from SS. Maybe there is an issue with solution? Solution was converted from vs2005.
You shouldn't localize an asp.net site by duplicating pages or controls. You use, for example, language specific resource files that are referenced in the one page or control. Have a look at this for a start on how to localize asp.net websites.
I agree with #Joe R, copying code is not a good way to localize. You may feel like you have gone too far down this road to change your approach, but in the long run you will be much happier and more productive with a different solution.
At the minimum I would switch to a different approach for the rest of the localization, finish the project, and then go back later and convert what you have already done to the new method.
Take a look at the following:
Globalization and localization
demystified in ASP.NET 2.0
How
do you localize a database driven
website
If you need a quick fix for your problem, you'll need to give new names to all of the pages and controls you copied. The error comes from having two user controls with the same name (just like it says).
However, everyone else is correct in that you are going about this the wrong way. What happens when you need to change some code? It will cause extra maintenance because you need to make changes in two places. More than likely, you will forget one, and you'll end up wasting a lot of time. If you invest in using language resource files now, you'll save on headaches later. And, I'm not even mentioning the possibility of needing to add an additional language down the road.
Edit
Try the following if you still don't want to use language resource files.
Put the non-language specific code into a separate .cs file. Make sure it inherits from System.Web.UI.UserControl
In ASCX 1, make sure its ascx.cs class inherits from your class you created in step 1.
In ASCX 2, make sure its ascx.cs class inherits from your class you created in step 2.
I have written a data browsing library that is being used in several projects. The library or component includes some classes as well as some ASPX pages.
Until now, we copy all the files into each project to reuse it, with the obvious drawbacks and updating nightmares. I want to encapsulate all the library into a component that the projects can use.
What's the best way to do it? I know I can create a DLL, but I think it's only for the classes, don't know how to go with the ASPXs pages.
We are using Visual Studio 2008 and Framework 2.0
Thanks in advance
This is a perfect case for custom controls.
Change the pages into user controls, and embed the new user controls back into pages that have nothing in them but the reference to the user control.
Once that works, you can change the user controls into server controls, little by little. They will be composite controls, as the user control already is.
There's a trick you can use at this stage: I'm not recalling the details this late at night, but someone else will fill those in: when ASP.NET compiles a page, it first "compiles" the markup into source code, then compiles the source code. You can get ASP.NET to not delete the temporary source files. That allows you to copy into your project code that creates precisely the same HTML as the user control did.
The difference will be - it's now your code and you can refactor it as much as you like, or even include it in a custom control library.