I have a website which uses a web user control... well, basically all over the place. It's even included in other web user controls.
So I thought I could just upload the new source and it would recompile on the fly and be fine, but instead every page or control that uses it complains about a type mismatch. Because it is used in so many places, it very quickly becomes easier to just update the entire website. (Or at least it would if I didn't need to go through our change management process for that...)
So is there something I'm missing? Isn't there any way to upload a web user control and have it recompile like when you update a single web page?
I think it is recompiling, it just takes a bit and you have a conflict with the mismatched .ascx and .ascx.cs files in Temporary ASP.NET Files while it recompiles. I could be wrong about this. Personally, I've had better success if I always upload both the .ascx and .ascx.cs files together.
I would think that if you pushed these items you should be good... any less and you might have issues:
bin contents - this will include your code changes to the user control and if the assembly version changes you will want to include any .dll that use it, I have run into issues to many times by trying to push just a single .dll that is in the bin.
.ascx file
I don't think you would need to push any other .aspx or .ascx files.
Related
I have a published website and I need to change only the ViewPage(.aspx) code that is giving me an error. If I change that viewpage will it be ok or will I have to publish the website again? If there is no need to publish the website, does it work for css, javascript/jquery files?
If you are only changing visual elements (or in line code that don't rely on a new Project.dll being created) then there is no need to publish the website as long as you are updating the files on the server. If you want VS to send the files to the server for you then you will need to re-publish it.
Publishing is an easy way to build your project, package it and send it to the server so you don't have to mess about with individual files. If you just want to change one file, be it .js , .css or alike then you can just change it.
Depends on what you're changing...
If you're changing elements that have a direct impact with the codebehind in the aspx.cs, then you'll get a runtime error. For instance, suppose you have an aspx textbox and you change the textbox to a radiobutton, or you change the textbox's id field then you'll have to compile the solution and publish the visual page along with the dll to the server.
If, on the other hand, you're just changing css, javascript, or html, and you're sure that does not have an impact on the codebehind, then you can just publish the visual page.
If you change the code of views, then you don't need to publish the site again. If you change code behind then you must publish the dll. When you change the code the dll of your project changes.
I need to know if it recompiles my site at all or if there are any issues doing this. I have tested the changes locally and in a test environment and I don't want to do a full deployment for one tiny change. I'm just not familiar with aspx.vb files and how they interact with a website.
The short answer is yes, it will cause the page to be dynamically recompiled. Dependencies could cause the entire site to be recompiled.
For more information read this MSDN article: Understanding ASP.NET Dynamic Compilation. The "Recompiling on Change" section addresses your question.
You can modify an .aspx.vb file and drop it into its respective location on the server, overwriting the existing file, and it will be dynamically compiled due to the change. However, if you were referring to having code that changed .vb file content on the fly, that sounds like a bad idea and you should reconsider your problem and approach.
How can I make a dll of my web application usercontrol?
I have usercontrol222.ascx, but I want to make a dll out of this usercontrol.
Create a project containing only your user control ("usercontrol222.ascx") and grab the control's dll from the deployment of your new project. Here's the source of this method with a more complete explanation: Turning an .ascx User Control into a Redistributable Custom Control (Notable excerpts below, see the link for the full run-down).
Step 3: Use the Publish Command to Precompile the Site
The next step is to use the new
Publish command to precompile your
site and turn your user control into a
potential custom control. You'll find
the command under Build / Publish Web
Site. In the Publish dialog, do the
following:
Pick a Target Location. This is the location on your hard drive that your
site will be precompiled to.
Deselect "Allow this precompiled site to be updatable". In updatable
mode, only the code behind file (if
any) would get compiled, and the ascx
would be left unprocessed. This is
useful in some scenarios, but is not
what you want here since you want the
resulting DLL to be self-contained.
Select "Use fixed naming and single page assemblies". This will guarantee
that your user control will be
compiled into a single assembly that
will have a name based on the ascx
file. If you don't check this option,
your user control could be compiled
together with other pages and user
controls (if you had some), and the
assembly would receive a random name
that would be more difficult to work
with.
Step 4: Finding the Resulting Custom Control
Now, using the Windows
Explorer or a command-line window,
let's go to the directory you
specified as the target so we can see
what was generated. You will see a
number of files there, but let's focus
on the one that is relevant to our
goal of turning the user control into
a custom control.
In the "bin" directory, you will find
a file named something like
App_Web_MyTestUC.ascx.cdcab7d2.dll.
You are basically done, as this file
is your user control transformed into
a custom control! The only thing
that's left to do is to actually use
it.
You cannot. User controls are for the simplified scenario where you do not want to create a custom control. They have the disadvantage that the .ascx file and any other artifacts (images, styles, etc) must be included in each web site that uses the user control.
If you need complete reuse between projects, then you need to create a custom control. That's not actually that hard, if you directly translate the user control into a custom control.
You may want to look at developing your own server controls. See the following similar discussion: ASP.NET Web User Control Library.
I'm using a web deployment project in order to precompile my ASP.NET 3.5 web project. It creates a single extra DLL for the code in aspx and ascx files. And, for every aspx file there is a placeholder aspx file (empty) which needs to be copied to the server.
I'd like to simplify the deployment process. Is there a way (configuring the IIS site and adding some sort of http handlers etc.) to get rid of these aspx placeholders?
Also, I'd like to know if there is a way to get rid of the .compiled files in the bin folder. It would make the deployment process smoother.
Thanks!
I discovered it by myself. It is much easier than I thought (IIS 6.0):
In Internet Information Manager go to the property page of the site, then chose the tab "Home Directory" and click on the button "Configuration...".
Click "Edit..." for the .aspx ISAPI extension and uncheck "Verify that file exists". At this point, no aspx file is needed anymore.
Update
One important thing: I had to create an empty "default.aspx" file in the root of the application in order to allow the default document for requests like "http://www.example.com/" (without calling an aspx).
Update 2
Another very important thing: if you're using ASP.NET Ajax PageMethods, then you have to keep the aspx placeholder of that page. If you're omitting the file, a javascript 'PageMethods is undefined' error will be thrown on the browser.
IF it is possible, then it will require, at the least, the mapping in IIS of all possible requests to the asp.net engine. Not very difficult. Then, a HttpHandler should be possible to intercept all incoming requests. That handler should then be able to dynamically load compiled page classes and render them. You'd basically have a single engine DLL that serves page content.
But as you might have noticed from all the should's, it's not a simple thing to accomplish, and I doubt that it's really worth the trouble. What exactly is wrong with these placeholder files being present?
Simple question. If you have a compiled and published ASP.NET web application running on a server and you need to update, say, a line in one of the codebehind files. Do you shut down the entire site, republish, then load the site back up? Or do you publish straight to your live site with users still using it?
For myself, place an app.offline app_offline.htm file into the site, then overwrite the entire website with the latest published build.
there are a few options when building a site -> one dll for the site or one per page. if u just updated one line in a code behind, and you have chosen the build option for one per page, then you can just copy/paste that new page dll.
i don't like that method personally. I find it simple to app_offline.htm the site.
If it is a single file and a simple site that uses that app_code folder to store the code behinds, I simply xcopy up the new files. If I use http expiration headers I may need to do some better scheduling to make sure things like javascript files and css sheets match the rest of the site that was updated.
For emergency patches:
If its just a codebehind file, I copy the entire /bin/ out and replace all DLL's (mostly out of habit)
If its an aspx, I just copy the aspx.
For actual deployments, I have an automated system that checks out the code from source control, builds a clean release build, takes the site offline, and then robocopies it out to the deployment target. Its a one click process (Thanks CruiseControl!).