We have VS2010, ASP.NET 4.0 web site (not web project). Multiple developers work on it. I need this site to reference AjaxControlToolkit.dll. So, I checked in AjaxControlToolkit.dll into source control, then right-clicked on the web site, went to Property Pages, References, clicked Add, then added AjaxControlToolkit.dll.
As a result of my action, AjaxControlToolkit.dll was copied to BIN folder of the web site. So, all works fine on my machine. But, I see no record anywhere in the solution or project files that AjaxControlToolkit.dll is referenced from the web site.
Since we don't check in BIN folders or any .user or .suo files into the source control, when another developer gets latest, AjaxControlToolkit.dll is missing from the BIN folder and he/she gets an error until he/she adds the DLL to the BIN folder.
Is there any way to add a DLL reference to a web site and have that reference persisted on different machines?
Thanks.
At my current company, we create a folder in the project called "ReferencedAssemblies". All external (non .NET) assemblies are located in and referenced from this folder.
This way, you also guarantee that any updates to an external assembly are present whenever a developer performs a "Get Latest" or when the project is deployed.
HTH.
Web sites don't have project files which is where you would typically find references so you will not be able to reference the assembly other than having it in the bin of the web site or in the GAC of the machine where the site is running.
The only references that you will find to assemblies in a web site are the add assembly tags in the web.config, the register tags in pages and user controls, and the licenses.licx file if you are using controls that require licensing such as Infragistics.
Your options are to either set up all of the development machines to already have the assembly or to use a WebApplicationProject so that you can add a folder with the assemblies and add the references to the project with either a hint path set or a reference path set in your project so that visual studio can find the assembly.
You can store the referenced DLL in a 'References' directory that is source controlled then put the relative path to it inside a [dll name].refresh file in the website's /bin folder. Also source control the .refresh file.
Everytime Visual Studio compiles your ASP.NET website, it'll use the .refresh file to find the DLL in the 'References' directory and copy it to your /bin folder.
So for example, if your website references ThirdParty.dll, Set up your structure like so:
\References
\ThirdParty.dll
\MySite
\bin
\ThirdParty.dll.refresh
Then in ThirdParty.dll.refresh have this line
../../References/ThirdParty.dll
Related
Can't google with a success an info about: from what parts does the built Asp web forms application consists? In a Debug folder I see only dlls, but as far as I understand the aspx pages and a web.config file should exist. Any links?
The BIN folder contains the compiled code behind. The ASPX pages and web.config stay in the same place, the root directory of your application.
Further reading:
ASP.NET Web Project Folder Structure
How to: Publish Web Application Projects
Asp applications, unlike windows forms applications need to be published first.
Right click on your project and click publish. From there pick file system option and publish to wherever you want on your computer.
Those files are the ones you upload to ftp server.
Can anyone explain, please, exactly how .net works. I create a web site in Visual Studio and publish it to a local server to a folder at
D:\WebSites\Project1
I create a web site in IIS and provide the address of the folder containing the files for the web site. When I publish the site, using 'fixed naming and single page assemblies', all the .aspx files go in the folder on the D drive and a dll for each page goes in the bin folder inside that folder.
I would assume that when someone wants to view a page in their browser, IIS retrieves the file(s) required from the folder specified, they get processed and turned into html and sent to the browser.
Recently when someone clicked a button on a page that calls a web service - a file not found error was reported. Apparently
C:\Temp\bx5tn2js.dll
could not be found. The thing is - why did IIS decide to look in C:\Temp for a file?
And, in the error message was a load of references to xml serialization. What is being serialized?
This file looks like the compile files that asp.net generates on compile.
This folder can be setup on web.config on compilation session with the
tempDirectory="C:\Temp"
If you do not have set this option asp.net is use a default folder that is usually inside the asp.net directory, inside the windows folder. But if you have set this, and this folder did not have the correct permissions, then asp.net fails to compile the project, and you can get a message like that.
So I just got a site hosted at hostasp.net. In VS I'm working with a web site not a web application. In the control panel on the host under my site I have folders (data, logs, wwwroot). My current project only has 1 javascript file, 1 aspx page, and a web.config. I placed Default.aspx & web.config directly under wwwroot. In VS my javascript file is in a subfolder named Scripts so I created this subfolder on the host site and placed my javascript file in there.
When I access my site I get "Server Error in '/' Application." error. What am I messing up here?
Also if I have a code behind file, where do I put that? Should it be compiled somehow? When I built the VS project it doesn't give me any dll for it or anything. Right now I don't have anything in the code behind but just wondering for later if I do.
If you are using Visual Studio:
You can certainly just copy the files to your live server. Your "code behind" files will be compiled at run time.
You can Publish a Web Site or Web application so you have the option to pre-compile (to dll) all your code (and will be in /bin folder).
If you want to remove the "guessing" of which files you need to "push" to your live server. You can publish to your local file system or directly to FTP. VS will pre-compile your Web Site or Web Application, and "collect" all the necessary files that make up your web site/application and save it in the folder/FTP site you designate.
If you chose to publish to file system, then all you have to do is copy/ftp (whatever) to your live site. You might ask why even publish to local (first) only to FTP it anyway? So you can get fully acquainted with how all of this works - the different publish options, etc. locally (which is essentially the exact structure of your production site).
Publish Web Site (VS):
Publish Web Application (VS):
The only time this may not work is when your host doesn't have the "bits" that you might have. E.g. not all hosts may have the latest/greatest from Microsoft, like say, Web API and all the assemblies it entails.
But again, the tooling can help with Add Deployable Dependencies...which does and when you publish, the dependencies are all "bin deployed" (meaning they'll be in the /bin folder):
Hth...
I'd like to enable the resource files to be editable after deployment. I read this post which suggests that this is possible, but I can't seem to figure out what settings I need to change to enable this.
I have added the App_GlobalResources folder to my ASP.NET 3.5 "Web Application" and added a resource file to this folder. I assume that the Build Action for this file needs to be changed, but no matter what I change the Build Action to, I cannot achieve the above stated functionality.
The App_GlobalResources folder and the resource file are copied into the bin directory. Once deployed, any edits to the .resx file are not being displayed.
Any ideas?
You can achieve this, and I just did it.
Select the resource file in your project. Change the Build Action to content. Make sure that the Copy to Output Directory setting is turned OFF. When you deploy your project, the App_GlobalResources directory and your .resx file will get copied to the root of your web site. You can modify the .resx file and your live site will recognize the changes.
A Web Application project is different than a Web Site project. I doubt you can achieve what you want with a Web Application project. You might check out this post:
ASP.NET Web Site or ASP.NET Web Application?
Resources are generally meant to be static. They are items such as images, strings, and files that your program consumes and can rely on being present, (and therefore can be strongly typed in the case of strings/RESX files). The reason for using resources is simply to bundle them in with your DLL's so that distribution and referencing the resources becomes much easier.
Editable at runtime suggests you might want to use project or user Settings, or maybe a database? If you need to use RESX files you might need to write code to read/write them.
I've created a web deployment project using the template for Visual Studio 2008 for a ASP.NET 3.5 web application (not web site).
I compiled the project which created the files needed for deployment. I copied the resulting folders (bin, static files and all folders with the aspx placeholders etc.) to a staging server where I wanted to test the application.
If I don't flag the option "Allow this precompiled site to be updatable", I get this error message on every page I load in the browser:
System.Web.HttpException file PAGENAME.aspx has not been pre-compiled,
and cannot be requested.
the last line in the stack trace:
System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(
VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp,
Boolean allowBuildInPrecompile) +8756366
If I check the option, everything is fine (I guess because the actual aspx/ascx are still there in their original form).
Any idea what I am missing here? Is there some setting or special file I forgot to copy?
Thank you!
Notes:
I have a few references to third-party assemblies
I've checked the bin folder on the staging server. It contains the precompiled assembly which contains all classes (I used Reflector to analyze the assembly).
All the ASPX files should only contain
This is a marker file generated by
the precompilation tool, and should
not be deleted!
Delete everything in your bin folder and publish the web again.
Make sure you take the files from the directory where you did the publishing.
Make sure you copy the .compiled files contained in the bin folder too.
For the record, I forgot to copy these ".compiled" files (MSDN documentation: File Handling During ASP.NET Precompilation):
For executable files in an ASP.NET Web
application, the compiler assemblies
and files with the .compiled file name
extension. The assembly name is
generated by the compiler. The
.compiled file does not contain
executable code. Instead, it contains
only the information that ASP.NET
needs to find the appropriate
assembly.
After the precompiled application is
deployed, ASP.NET uses the assemblies
in the Bin folder to process requests.
The precompilation output includes
.aspx or .asmx files as placeholders
for pages. The placeholder files
contain no code. They exist only to
provide a way to invoke ASP.NET for a
specific page request and so that file
permissions can be set to restrict
access to the pages.