I published the code with Visual Studio 2010 and then deployed the pulished code on production server.
Everthing is working fine.
Suppose if I need to make some changes in code behind file (.cs file). Do I need to publish the code again and again from visual studio 2010?
Or Can I just need to replace the bin folder on production server?
Currenlty I publish the code each time I change the code in code behind file and replace the publish code on production server.
Your bin directory will contain your compiled code so if that's all you change you can only deploy the bin folder.
But when you change other files, like your web.config, aspx, css or javascript files, those changes will not show up in your bin directory. Those physical files will need to be deployed.
Because deploying can be a tedious and repetitive process, it would be best to automate this. If you setup your webserver for WebDeploy, you can automatically deploy from Visual Studio to your server. WebDeploy will keep track of all changes and make sure they are deployed.
if you chage .cs files only, then you can replace dll files.
when you publish:
If you choose Replace matching files, it copies only changed files
it is equal to replace dll as above and also it is better option than doing it manually.
sometimes we may have changes css or javascripts but forgot to add them.
If you try to modify the code behind code, you don't have to republish the whole project and just need to override the production files. Because it is a partial class of aspx page and is compiled at runtime.
But it is better to do it automatically using some tools. It can avoid human mistakes and run your test to make sure your change doesn't break any functions.
Related
I am developing a piece of an existing web site and am having numerous issues trying to upload my files to the server. Everything runs fine locally, but once I put my files on the server things start breaking.
Right now I have a page that gets this error
"Parser Error Message: Could not load type '[Namespace].[PageName]'
. If I take out the inherits statement, it works. The namespace and the pagename are declared in the code behind, which is referenced in the page header.
I also just noticed that all of the pages that predate me don't have code behinds.
There are two options for putting a file on a web server.
One option is to compile it and use a "Publish" feature, in which all of your code-behind files are NOT on the server, and are instead are compiled down to the .dll.
Another is to not compile the site, and simply copy all the aspx ans .cs (or .vb) files out there, uncompiled.
Actually there are three, but I think you only need to deal with these two right now. They are described further at http://msdn.microsoft.com/en-us/library/ms178466(v=vs.100).aspx under the "Flexible Deployment" section.
Your predecessor apparently used the first method. The only way to fix this is to get the compiled .dll files out of the \bin directory, and decompile them using a tool like Reflector or Teleriks's Just Decompile. (The latter is free, the former has a free for a limited time trial period.)
Alternatively, if you can get the full source code, you can simply remove all the content already out ther and publish it using the non-compiled method. Of course, there will be down time, and you'll need to test pretty carefully...
When you have a codebehind file, it needs to get compiled into a DLL, and that DLL needs to be in the bin directory of the webserver. It doesn't actually work fine without the Inherits - nothing from your codebehind would be in there - it may only display ok initially, but none of the events would fire.
If the rest of the site is all done with the code included in the .aspx pages, then those pages are all standalone. But if you want to use codebehinds, then you'll need to publish the DLL.
Test easiest way to get your code up and running would be publishing the code. Inside of your project in Visual Studio right click on your application and click on publish then for the location you can just create a folder on your local system and select only files needed to run this application then select publish. It will only copy the files needed to run the application and you can copy those files to your server and everything should be correct. I will also copy your web.config/app.config file so make sure that everything is correct in that file or delete that file from the directory once the publish is done.
So I eventually talked to the lead developer for the other group that works on the site. He explained that they do a Solution Rebuild then just move any changed as*x files and the /bin .dll. For some reason, my subversion client didn't actually update anything when I asked it to update, so my branch didn't have some new controls the other group made. When I would build my solution it didn't include the .dlls for the new controls, so when I uploaded my dll the new controls weren't defined and I got the same message. When I took the new dll down, my controls weren't defined.
Anyway, I fixed that. Thanks for the answers.
I have a web app that has an app_offline.htm file, this file is stored in source control along with everything else.
The problem I have is that each time I (or any other developer) do a get latest on the source I get the app_offline.htm file and then when I try to run the app all I see is the app_offline rather than the actual web site.
Is there way that I can stop this from happening?
You can right click on the file and choose exclude from project. It renames the file so you IIS won't pick it up, but I'm pretty sure that Visual Studio will not remember that after you do a new checkout. (Can't verify this though)
Other than renaming it or removing it locally, it most certainly depends on your source control system. The whole point of source control is to "restore" a code source to a specific point. Checking out something other than the current state is kind of against the source controls principle..
Can you perhaps rename the file in source control and when you publish it you rename it to app_offline.htm then instead?
Using a Visual Studio 2010 ASP.net web application, I have several projects that share some JavaScript/css files. The most logical way for them to share these files is to place the files in a single folder and each project has them included with the "Add as Link" option. However, if I add the files this way when I'm debugging using either the Visual Studio Development server or debugging using a local IIS web server all requests for these files return 404 Not Found errors. If I publish the site then the files are copied but that obviously doesn't help with debugging.
Is there something I'm missing or is this a failing on VS's part?
To overcome this problem some time ago I created a 'MSBuild.WebApplication.CopyContentLinkedFiles' nuget package. This package adds MsBuild target which copies all content files added as link to project folder during build.
Note: if you use source control then it is better to add copied files (from Web Application folder) to ignore list.
I wouldn't really call that a failing, since you asked for that behavior in the first place: linked items in Visual Studio projects are actual links to external files. Those files can reside anywhere on the disk and are not copied into the project folder.
You might want to copy those files locally yourself during a pre-build event. That way, the files will remain synchronized and you won't duplicate them until your first compile.
The problem seems to be that the website runs right from your source folders, rather than from the bin folder. This means that the file will be missing, whether or not it is copied to the output folder.
It's probable that running from a local or remote web server would not have this problem, though I didn't get that working, and I'd rather not add IIS to my local machine if I don't have to.
Adding a pre-build copy command did work. Note that the current directory will be the bin folder. (You can use cd to echo the current directory to the build window if you want to see it):
If the file is in another solution, your command will look something like (three ..s: one to get out of each of bin, project, and solution folders):
copy ..\..\..\OtherSolution\OtherProject\Scripts\MyJSFile.js ..\Scripts\
If it's in the same solution, but a different project:
copy ..\..\OtherProject\Scripts\MyJSFile.js ..\Scripts
One minor issue is that the link to the file will collide with the new copy of the file, even if you don't add it to your project. As long as you make the link first, it seems to work. If you copied the file first, you'll have to manually delete the copy, and then refresh the solution explorer before before being able to add the link.
Select the link in Solution Explorer and then look at properties window and set Copy To Output Directory to Copy Always. Linked items are set to Do Not Copy by default.
BTW, you can copy many files as links very easily directly from Solution Explorer when using VSCommands 2010 extension.
See this blog post about a simple addition to your project file.
http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx
I am developing an asp.net website that will need regular updates for source codes and HTML sides. After i have completed the necessary updates, i use the 'publish website tool' and publish the site to my local directory. Then i upload all files to Remote File. Is there any way to fix my site with just changed files. For example if i have updated just 2 files of 84 (HTML or source side), is it possible to update just this 2 files without any problem?
While Visual Studio does offer a few different compiling/build options, I think that you are probably doing everything just fine for a Visual Studio Website project. When I'm working with a website rather than a web application, I will only FTP the files that have changed. For example, if I were to change some HTML tags around within an .aspx page, then only that page would need to be uploaded to the web server. If I change the Page_Load function in the .aspx.cs page, then I will definitely need to get the updated DLL on the web server as well.
I use FileZilla for my FTP tool and there is an option to only upload the changed files. So after you use visual studio to publish your website, you can grab the entire contents of that directory and drag it over to the FTP server location and only update what has changed.
The ASP.NET website project offers an option in the Project properties -> "MSBuild Options" tabpage where you can set "Allow this precompiled site to be updatable".
Setting this option
"Specifies that the content of .aspx
pages are not compiled into an
assembly; instead, the markup is left
as-is, allowing you to change HTML and
client-side functionality after
precompiling the Web site. Selecting
this check box is equivalent to adding
the -u option to the
aspnet_compiler.exe command."
according to the docs.
I've been entirely underwhelmed by the available tools to VStudio. And am instead using Gulp.
Even in 2017 the problem remains.
With gulp you can "watch" directories for changed files, so I have it configured to watch the [bin] folder, along with assets separate from aspx/cshtml files.
That way whenever I change anything, it is instantly copied to my publish folder where I can later zip it up and deploy ONLY the changeset. The script even has a delay so I can delay the copy/upload in situations like bundles where they are generated dynamically and take some time to be fully modified.
The only thing I have to do is clean it up before I start my next milestone, so that the "publish" folder which gulp "auto deploys" to is empty and ready for the next run. Emptying a folder and running "gulp watch" in background seems like a small price to pay for such a needed feature.
I feel like this should be a good item to develop as a vstudio plugin.
Recently I have been forced to move to a windows/C#/.NET/MVC environment from linux/node/angular. Sigh. I found the following solution (next paragraph) elminates the pain caused when using visual studio to "publish" the code. The VS2017 publish process copies every file in the entire application to the web server, even if just one character is changed in one file. This can take over an hour for our moderately sized app.
So here's what I do. I first publish the solution locally (typically to bin/release/Publish/). That takes about 1 minute as opposed to 1 hour to publish to the server. Then, I compare the files between my local Publish directory and the server directory using FreeFileSync. FreeFileSync is amazing -- and free. I have access to the server directory via a windows file share. The compare takes about 15 minutes. I can then see exactly what files are different and need to be pushed. Note, the option I use compares the actual CONTENT of the files, not just the create time. I then use the FreeFileSync sync feature (mirror option) to copy the few files needed to the server. This takes maybe two minutes. So the total operation takes about 20% the time Visual Studio "Publish" takes. But best of all, the actual hit on the prod server is only the two minutes it takes to copy the diff files, rather than the 1 hour outage inflicted by Visual Studio Publish as it slogs along copying each and every file.
It depends on the type of project.
If is a project created with File > New Web Site then is ok to just copy the changed .aspx files (make sure that the corresponding code - .cs - files are also copied).
If the project was created with File > New Project > ASP.NET Web Application then you will need to copy the .aspx files and the compiled project dll (by default the dll has the same name as the project like TestProject.dll) from the bin folder inside the project.
i think you need something http://winmerge.org/
where it will compare files that are changed and upload them.
hope this helps
I'm using a deploy project to deploy my ASP.net web application.
When I build the deploy project, all the .compiled files are re-created.
Do I need to FTP them to the production web server?
If I do a small change do I need to copy all the web site again?
From my own research, the .compiled files must be copied to the production server, but not needed to copied every time
from Rick Strahl excellent blog:
The output from the merge utilitity
can combine all markup and CodeBeside
code into a single assembly, but you
will still end up with the .compiled
files which are required for ASP.NET
to associate the page requests with a
specific class contained in the
assembly. However, because the file
names generated are fixed you don’t
need to update these files unless you
add or remove pages. In effect this
means that in most situations you can
simply update the single assembly to
update your Web.
Source
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
There's nothing special about .compiled files: it's just the actual file with a .compiled extension on the end so that nothing happens if you accidentally double click it.
But if you're seeing .compiled files, you're publishing your app in such a way that it expects to be formally installed- it's not enough to just copy things to production. You have to run the installer program too. If this is an app you know is already deployed, that seems a bit unnecessary.