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.
Related
I have faced a lot of issues with Publishing like when you need to make small changes on the code, sometimes the generated DLL file (the dll file for example of default.aspx.CS when published) cannot be recognized by IIS saying the codebehind is wrong or something. Sorry for not remembering the exact error message. I am hoping you know what I mean at this point.
Therefore, I usually do a simple Copy Paste operation instead of Publishing.
Could you tell me what am I missing by NOT using the Publish method? How is Publishing better? Or which one do you prefer, why?
Basically its a pros and cons situation.
Thankyou
Well, it depends on what you mean by "copy":
With Publishing you have options to pre-compile all or part of your application. You can publish to a local folder in your file system (instead of your target/host) and then copy the updated file(s) (only). If you are making "code behind" (c#/vb code) changes, this means you'll likely only need to "copy"/overwrite dlls. Goes without saying that if you've made "content" changes (html/razor/script/etc) changes, then you'd need to copy/overwrite those as well.
If you're new to deployment, you may find yourself simply copying/overwriting "everything" which is the safest way to go. Once you get more experience, you'll "recognize" which assets you only need to update (one or a few dlls and or content code, instead of "everything"). There's no magic to this, usually, its a matter of just looking at the timestamp of the dll/file after you've published (locally) or rebuild your web application.
I'd recommend doing a local publish so you can see what is actually needed on your server. The files published to your local file system/folder is what needs to be on your host/server. Doing so will visualize and remove whatever "mystery" there is to Publishing:
you'll see what is actually needed (on your server) vs. what's not
you'll see the file timesstamps which will help you recognize what files were actually changed vs those that weren't (and therefore don't need to be updated).
once you get the hang of it, you will not need to "copy"/ftp "everything" and just update files that were actually modified (only).
So "copy" can mean the above, or if you are saying you will simply copy all of your development code (raw (vb/cs)html/cs/vb) to your host, then that means your site will be dynamically compiled as each resource is needed/requested (nothing is pre-compiled). Also "easy" but you do lose pre-compilation which means there is a delay when each of your web pages are requested/needed (ASP.net needs to dynamically compile). Additionally, you are also exposing your source code on the server. It may not mean much depending on your situation, but it is one more thing to consider.
Here's more info on pre-compilation and options.
Assuming we consider an aspx page and its aspx.cs code behind file, there are three alternative ways of deploying your site:
You can copy both to iis. The aspx will be compiled to .cs upon the first request and then both .cses will be compiled to a temp .dll
You can "publish" to iis, this will compile the code behind class to .dll but will copy the aspx untouched. The aspx will be translated to .cs and then to .dll upon the first request
You can "publish" the site and then manually precompile it with the aspnet_compiler. Publishing will compile the code behind to .dll as previously but then precompilation will clear out your .aspx files by removing their content and moving the compiled code to yet another .dll.
All three models have their pros and cons.
First one is the easiest to update incrementally but in the same time is the most open to unwanted modifications.
Second is also easy, can be invoked from vs, it closes the possibility of some unwanted modifications at the server but .aspxses still need time to compile upon the first request
Third takes the time and some manual actions but prevents any changes and also speeds up the warm up of the site as the compilation of assets is not necessary. It is great for shared environments.
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
For example how this site is organized?
What i do not understand is what they upload to the Microsoft server?
I have created, with Visual studio, a very small web-page and i have to upload the whole site, even after the smallest change...
The usual approach is to replace everything with xcopy or the publish function in visual-studio, and in some cases replacing everything is the only approach - for example if you're using the web-application project model everything gets packaged into a single assembly and there you go - even to apply a small change you'll have to re-deploy the whole thing.
An alternative to this could be the Website model in visual studio, using which you should be able to deploy single code files on your server and they should be picked-up if you re-start the website from the IIS management tool. This model - in fact - works in a different way compared to the web-application project model. It's just a bunch of code files that will be dynamically compiled by the ASP.NET runtime.
Even if possible though - I wouldn't suggest the approach of deploying single files - as this is easily error prone (you deploy the code-behind and could easily forget to deploy the aspx counterpart, or similar). Unless you're delpoying Gigs of stuff over slow-networks, redeploying the whole thing is always the safest bet.
Have a look at this and this interesting links to find out more about website and web-application project models in visual studio.
It really depends a lot on how you're building your app.
If you're in VS and you're doing an ASP.Net site, then you can either do it as a Website Project, or as a Web Application project.
in the former case, your files will remain as aspx and .aspx.cs files and you xcopy (or FTP) whichever files change. if you want logic that's outside the scope of a single page, you'll either create a separate class library project or else use the App_code directory.
In the latter case, you'll compile all the logic into one or more .dll files that get copied to your site's /bin directory, and any number of aspx files that can either stay as such or be embedded (recommend leaving them as aspx files). Again, if an aspx file changes, you just movethe one that changed, if anything in the dll changes, you replace a whole dll.
All that said, a huge chunk of what's on the site you posted is probably being pulled out of the database. Most sites now dont' have content on pages, they just have organizational (view) logic on paes, and have other classes which fetch the actual content out of a database to serve up. This allows greater reuse and means that the 4,000 pages (number chosen at random) on MSDN don't have to be each coded individually as an HTML page.
After Googling i think, the check-box Use fixed naming and single page assemblies in the publish Website form of the Visual studio, is the right choice.
Although it might slow things down...
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