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.
Related
I have quite a number of user controls that I need to embed in Umbraco macros. Each user control has quite a bit of in page javascript that needs loaded into the page.
I have been building up the javascript with StringBuilder.Appendline then registering a startup script with code behind but this stinks and I feel there has to be a better way of going about this.
Has anyone any ideas please?
Thanks,
B
If the javascript isn't dynamic, that is that it changes based on the usercontrol you would probably be best to extract it and put it in either one .js file for the site or in a number of them. Doing so allows it to be cached by the browser.
If it is dynamic then I would personally keep it isolated inside the control rather than try to write it out all at once. I don't believe there is any major performance hit from having several script blocks, although I could be wrong.
When I generate code using T4 templates in Visual Studio 2010, I get the following error for each of my asp controls when I try to compile:
Control "ddState" is missing required attribute "showat".
I have never gotten this error in previous versions of .NET. Further, I don't get this error when I manually construct my pages either by dragging/dropping, nor do I get it when I type out the control text myself. When I generate code, I have to manually add showat="client" to my tag for the compiler to be happy. It was my understanding that I never had to explicitly specify this tag. The following:
<asp:dropdownlist id="ddState" runat="server" showat="client" />
solves the problem. Why do I have to add this to generated code but not other times?
(It's a VS-2010 webforms project, using VB, in case that makes a difference.)
Apparently .NET 5 or another one of those super service packs is going to allow something called targeted rendering. It was originally intended for use just in the context of webforms, but I've heard recently there will be some fancy way to use it in MVC (using some helper classes) and in services using WCF. It will work well with Dynamic Data but is very loosely coupled with it; you can use one or the other completely independently. If you configure your dynamic data with certain tags you can have it constructed on the client, etc.
For now, just put showat="client" in all your tags, and all is good. That's supposed to be the implicit default, but I've heard of cases where the IDE seems to require it. In the future, showat="client" will be the safest setting anyway, giving the expected behavior in 99.9% of cases.
This is required in VB, but not C#, which is why it seems to not be necessary sometimes. To be more specific, the C# compiler puts the equivalent of showat=client into the IL automatically, unless you specify a showat target other than client.
"showat='client'" should currently have little effect on your coding. It's main purpose is for future WCF output targeting, which they will want to be backward compatible. For now, the only possible value is "client", but in the future there will be other possible values that will allow pre-rendering of cached values, and apparently "pushing" output to services. The example I saw at the last code camp was where you could push to a service at (probably) the same site as well as to the client machine, for logging/debugging purposes. You'd have something like (to use your example):
<asp:dropdownlist id="ddlCP" runat="server" showat="client, logService" />
. . . and then the rendering would go to your log file. Or, to your session provider (if you've got multiple web servers and are implementing a shared session provider), etc. I think logService above would have to be defined in the web.config or something.
Check to see if VB does anything in the web form designer page when you use the IDE to add the control. I'm not sure how VB inserts the implicit tag. But that would be something the T4 template would miss, just a thought...
Agreed that my VS2010 solves this issue for you. Then you can remove the tags completely. I would suggest getting the upgrade. It's well work the $599 upgrade cost. Otherwise, look to add the showat="client" in all the tags. I think that Rising Star got that one right, although I haven't tested it yet.
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.
I'm an ASP.NET web part novice. I've built a few simple ones using only a class that derived from WebPart and overriding the CreateChildControls method, but nothing really very substantial. My question is whether it's possible to have a web part that also takes advantage of a separate html/asp.net markup file that will help provide some structure to the web part's output. In the past I just created server controls and added them to the controls collection, but this seems like a silly way to try to create a non-trivial layout. Can I do this? Do I have to use an ascx user control or can I bypass that step? There are a lot of hello world tutorials on web parts out there, but none seem to go past the CreateChildControls override. Thanks!
Yes, there is. Go here to learn about templated web parts, and go here to see all of the info he has on WebParts. I used this technique back in 2004/2005 and it worked very well.
The links in the above answer are no longer working, but here is an alternative one:
http://www.a2zdotnet.com/View.aspx?Id=95
In VS 2010 we also have visual web parts, that I think do pretty much the same trick but it's wrapped in a project item. I've only seen this in the context of SharePoint so not sure how it works for ASP.NET projects. Here is an example:
http://msdn.microsoft.com/en-us/library/ff597539.aspx
I wonder what the best practice for this scenario is:
I have a Sharepoint Site (MOSS2007) with an ASPX Page on it. However, I cannot use any inline source and stuff like Event handlers do not work, because Sharepoint does not allow Server Side Script on ASPX Pages per default.
Two solutions:
Change the PageParserPath in web.config as per this site
<PageParserPaths>
<PageParserPath VirtualPath="/pages/test.aspx"
CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>
Create all the controls and Wire them up to Events in the .CS File, thus completely eliminating some of the benefits of ASP.net
I wonder, what the best practice would be? Number one looks like it's the correct choice, but changing the web.config is something I want to use sparingly whenever possible.
So in that case I would wrap it up in a feature and deploy it via a solution. This way I think you will avoid the issue you are seeing. This is especially useful if you plan to use this functionality within other sites too.
You can also embed web parts directly in the page, much like you do a WebControl, thereby avoiding any gallery clutter.
What does the ASPX page do? What functionality does it add? How are you adding the page into the site? By the looks of it this is just a "Web Part Page" in a document library.
I would have to do a little research to be 100%, but my understanding is that inline code is ok, providing it's in a page that remains ghosted, and thereby trusted. Can you add your functionality into the site via a feature?
I would avoide option 1, seems like bad advice to me. Allowing server side code in your page is a security risk as it then becomes possible for someone to inject malicious code. Sure you can secure the page, but we are talking remote execution with likely some pretty serious permissions.
Thanks so far. I've successfully tried Andrew Connel's solution:
http://www.andrewconnell.com/blog/articles/UsingCodeBehindFilesInSharePointSites.aspx
Wrapping it into a solution is part of that, but the main problem was how to get the code into that, and it's more leaning towards Option 2 without having to create the controls in code.
What I was missing:
In the .cs File, it is required to manually add the "protected Button Trigger;" stuff, because there is no automatically generated .designer.cs file when using a class library.
Well, it's a page that hosts user controls. It's a custom .aspx Page that will be created on the site, specially because I do not want to create WebParts.
It's essentially an application running within Sharepoint, utilizing Lists and other functions, but all the functionality is only useful within the application, so flooding the web part gallery with countless web parts that only work in one place is something i'd like to avoid.