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.
Related
I am very new with ASP.NET. I need help understanding the basic procedures of how a developer publishes their site to their hosting server, and then once its compiled and published, how does another developer (someone who does not have the original files), edit some of the code behind files.
For example, Developer A creates a site, uploads it to the server and it works great. We hire a new remote developer (Developer B) and he needs to work on a .cs file, does he need to get a copy of the entire site, to his local machine? if so, does he need to reverse the compiling process to get thos .cs files back?
I am a PHP developer, and since theres no compiling needed, I dont worry about .dlls nor about compiling at all. This would truly help me understand ASP.NET with the hopes that it can also help others like me.
Please help. Thank you in advance.
You do not need a copy of the entire site.
But you need the basic struct of an asp.net site, and what resource you may need to run this individual page.
The minimal basic struct of an asp.net site is this two directories (and the content of them - if any)
App_Code
Bin
together with the web.config that is probably needs some changes to run to the remote developer.
Now some simple logic.
If a page have css, javascript and other files you need them too
If a page need connection to some database, you need that too
In the bin directory you may only give the dlls/libraries that this individual page use (if any)
If the page have links to other pages, or post to other pages, or need ajax call from other pages you need them too.
If some one change some functions on the dll files, you must give the update to the remote developer so he can adapt his code.
After the update he can upload the aspx + cs file on the server.
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 have a few applications that need to share a common set of markup.
Scenario: I might have www.site1.com, www.site2.com, and www.site3.com. On all sites, /care/contact-us.aspx and /care/faqs.aspx will be exactly the same, but every other page will be totally different.
Issue: I'm attempting to not duplicate the .aspx files for each of these sites and would like to have a /care virtual directory that would include contact-us.aspx and faqs.aspx that each of these sites would use. I have seen this post from Scott Gu, but I'm looking for any other solutions/ideas.
Question 1: What would be the best way to set this up to share the /care directory?
Question 2: Any ideas about also sharing the code behind.
Background, if you care: In a legacy application (asp classic/vbscript), we have the ability to use a /common virtual directory for sites to share common markup and code (since they're all mixed together in .asp files).
Thanks in advance to any help or ideas!
Simply setup a virtual directory in IIS for each of the apps that points to the same physical directory.
Here's a good reference:
http://support.microsoft.com/kb/324785
This is actually pretty hard, and i'd recommend you either bite the bullet and go with the scott gu answer or use the solution we chose, which was to use the svn:externals property within subversion to import a directory from a "shared" repository. Subversion manual reference. If you use a different version control system i would guess it would have something similar but you're on your own in that case.
I use a virtual directory in order to share HTML and Image files between sites. To share ASPX files, things are a bit different - and harder.
When we share HTML files, we do not just link to that file because it would screw up the menu (different sites have different menus - we just want the content of the HTML files). So I created a page (e.g. "ShowContent.aspx") that opens up the HTML file, reads the contents as a string and assigns the string to an ASP label control. This may work for you as-is if you don't generate the content dynamically in your shared ASPX files.
Even if you do, hope is not lost. First, create a project that incorporates JUST the common ASPX files, build it and place the project files in a known location (http://shared.yoururl.com). Now, instead of pulling the contents by accessing a file, simply read the contents off using a WebRequest object:
WebRequest wrContent = WebRequest.Create("http://shared.yoururl.com/CommonInformation.aspx");
Stream objStream = wrContent.GetResponse().GetResponseStream();
StreamReader objStreamReader = new StreamReader(objStream);
string pageContent = objStreamReader.ReadToEnd();
Then display the pageContent on your blank page.
If your common pages are data entry forms then I'm afraid your only hope is to place them in a common source directory that multiple projects share. You'd share the source but would publish the files with each project. This is likely to be messy though: you may make changes in one that break other projects because they now have the possibility of interdependency.
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.
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!).