Contact Support. Chatter isn't enabled or the user doesn't have Chatter access. Did this content resolve your issue? Yes No. Want to learn more? No information related to your case. Black Duck - User Guide. Version Please see attached PDF. Created By: Nicole Banks The important take away here is that for an ASP. NET page to be rendered by the runtime both its declarative and source code portions must be compiled into an assembly.
With WAPs, the source code is explicitly compiled into an assembly prior to deployment, but the declarative markup must still be converted into code and compiled by the runtime on the web server. With WSPs using automatic compilation, both the source code and the declarative markup need to be compiled by the web server.
It is possible to use explicit compilation with the WSP model. You can explicitly compile the source code portion, like with the WAP model. What's more, you can also compile the declarative markup.
This tool was released with the. NET Framework version 2. The compilation tool provides two general forms of compilation: in-place precompilation and precompilation for deployment. The compilation tool then compiles each ASP. NET Files folder just like if the pages had each been visited for the first time from a browser.
In-place precompilation can speed up the first request made to newly deployed ASP. NET pages on your site because it alleviates the runtime from needing to perform this step. However, in-place precompilation is not useful for the majority of hosted websites because it requires that you are able to run programs from the web server's command-line. In shared hosting environments this level of access is not permitted.
NET 2. Instead of compiling the pages in the website to the Temporary ASP. NET Files folder, precompilation for deployment compiles the pages to a directory of your choosing and in a format that can be deployed to the production environment. There are two flavors of precompilation for deployment that we explore in this tutorial: precompilation with an updatable user interface, and precompilation with a non-updatable user interface. Precompilation with an updatable user interface leaves the declarative markup in the.
Precompilation with a non-updatable user interface generates. The best way to understand precompilation for deployment is to see an example in action. The ASP. This section examines using the tool from within Visual Studio; the "Precompiling from the Command Line" section looks at running the compiler tool from the command line.
This launches the Publish Web Site dialog box see Figure 1 , where you can specify the target location, whether or not the precompiled site's user interface is updatable, and other compiler tool options. The target location can be a remote web server or FTP server, but for now choose a folder on your computer's hard drive. Because we want to precompile the site with an updatable user interface, leave the "Allow this precompiled site to be updatable" checkbox checked and click OK.
Figure 1 : The ASP. After precompiling the website, navigate to the target location you entered in the Publish Web Site dialog box. Take a moment to compare the contents of this folder with the contents of your website. Figure 2 shows the Book Reviews website folder. Note that it contains both. Also, note that the Bin directory includes only one file, Elmah.
Figure 2 : The Project Directory Contains. Figure 3 shows the target location folder whose contents were created by the ASP. NET compilation tool. This folder does not contain any code-behind files. Moreover, this folder's Bin directory includes several assemblies and two. Unlike explicit compilation in WAPs, the precompilation for deployment process does not create one assembly for the entire site.
Optional Boolean parameter If this parameter is true , the precompiled application will be built clean. Any previously compiled components will be recompiled. The default value is false. If this parameter is true , debug information. PDB file is emitted during compilation. If this parameter is true , the assembly is not fully signed when created. If this parameter is true , the compiled assemblies will be given fixed names.. Optional Boolean parameter If this parameter is true , the task will overwrite the target directory if it already exists.
Existing contents are lost. Optional String parameter. Specifies the physical path to the strong name key file.. Specifies the full IIS metabase path of the application. This parameter cannot be combined with the VirtualPath or PhysicalPath parameters. Specifies the physical path of the application to be compiled. If this parameter is missing, the IIS metabase is used to locate the application. Specifies the TargetFrameworkMoniker indicating which. If you need to override themes in a pre-compiled application, you have to explicitly override the theme for each page in the OnPreInit event of the page.
These files are not optional as they map the ASPX pages to the appropriate precompiled classes in the precompiled assemblies. If you remove the. NET error. I already showed the directory-level compilation mode. One really annoying aspect of this mode is that it creates new IDs for all of the files on each build. Notice that each assembly has a generated name, and any time you re-compile the site the names of the assemblies and support files change.
For deployment to a Web site this means that you pretty much need to completely redeploy all files in the BIN directory every time! Directory-level compilation is just one of about 20 compilation combinations available. Here is the command line to use fixed names mode. The one advantage of this approach is that it produces a repeatable install, but the file names still have a randomly generated hashcode at the end. However, it is possible to update just the pages or controls that have changed, unlike directory-level compilation where every single compiled file and its associated.
But there are a lot of assemblies generated. Copying these assemblies to a live server will cause your online application to become unstable and likely fail as the files are updated one at a time. Neither of these two approaches offers a really clean deployment scenario because you have to copy a lot of files.
Compared to ASP. When present this page is displayed whenever any request hits the ASP. NET pipeline. Another option is partial compilation, which compiles only the CodeBeside classes but leaves the ASPX pages to compile at run time on the server.
NET Compiler calls this an Updateable site , but this is only partially correct. When compiled with the -u option, the ASPX pages remain intact. In turn you will no longer need the. So the BIN directory looks a bit cleaner with this approach. However, now you need to make sure to deploy your ASPX pages and keep them in sync with the server.
Note that the Inherits tag includes the dynamically generated assembly name. Unless you use fixed names compilation, the assembly name will change on every build so you still have to update the page along with the assemblies if you use the default directory-level compilation.
To figure the compilation process option out, I built a small ASP. NET compiler for the most common options. The utility, shown in Figure 7 , allows you to play with the various compiler combinations and quickly see the results in the output folder. It can also generate a batch file for you and lets you jump directly to your FTP client to upload the code to the server.
As you can see there are lots of problems and no sensible deployment options with ASP. The best you can hope to do is a full re-deploy of your BIN directory that potentially contains a lot of files. Even before ASP. NET solution Figure 8. NET compiler creates from stock projects. There are actually several other options for compilation including creating directory-level assemblies or page-level assemblies, but WDP adds support for fixed names for each of these options so the compilation of these assemblies is repeatable.
NET compilation of your site and then merging the resulting assembly output into a single assembly, one per directory or one per page. In all cases, use repeatable names for the assemblies created.
The tool includes other options such as signing and versioning the resulting assemblies, as well as the ability to create a virtual directory in the output folder. It even has the facility to change the content of your web. You can run this utility against a compiled ASP. NET project and produce the desired assembly merging. I used this tool to provide the integration into the ASP. NET Compiler Tool shown in Figure 7 , which is compatible with this tool and can merge into a single assembly as well.
If you use stock projects with Visual Studio , WDP is a no-brainer since it produces much more manageable deployment output. The output generated still includes. In most update scenarios you only update the main assembly plus any changed support assemblies. Add to this the fact that stock projects are housed in a project format that is not like other standard Visual Studio projects and you have a recipe for grumbling developers who are used to a fairly straightforward compilation, project, and deployment model from previous versions of Visual Studio.
WAP brings back a more structured project style in Visual Studio that is in many ways more similar to a Visual Studio project, but at the same time embraces all of the new ASP.
Because the project is a standard Visual Studio. NET project, it automatically contains built-in support for XML comments, compiler directives, and assembly versioning, as well as MSBuild support, pre- and post-build events etc. All of these things that you take for granted in Visual Studio.
NET projects are missing in stock projects. In this model, Visual Studio is responsible for explicitly compiling all CodeBehind classes, and any other classes defined anywhere in the project. So, all of the code in your project compiles into a single assembly.
NET code in the same project any longer and you have to explicitly compile your code in Visual Studio each time you make a change to any of the CodeBehind classes. Debugging is also more exacting-a code change in most cases requires you to recompile and restart the debugger.
However, compilation is fast once again with WAP. I have one project with roughly 80 pages and control classes and it compiles in a couple of seconds. With stock projects a full compile took a painful seconds. WAP also supports Edit and Continue if and only if you use the built-in Web server to debug your applications.
The built-in Web server is required because Visual Studio needs to control the parent process it debugs when you use Edit and Continue. The single assembly compilation for all CodeBehind code does away with a lot of the problems regarding inheritance and control and page referencing, because every page and control of the Web project guarantees that it can freely reference every other control and page of the project, since they all end up in the same assembly.
The page parse tree classes are still separate, but all the base classes exist in a single assembly that defines both the control properties and custom method interface from your user code.
The class interface is no longer split across two classes as is the case in the CodeBeside model, which is the root of many of the problems I discussed earlier. It uses partial classes to separate out the user code and the designer-generated control definitions. So a WAP page consists of three different files:. By not generating code into the CodeBehind class, WAP keeps the user code file clean like stock projects, and also minimizes problems by keeping the designer file and visual designer surface in sync.
This seems like a subtle change but it has a big effect. By creating property definitions on the user code base class, the class interface is fully defined at this level and when Visual Studio compiles these classes into a single assembly, the classes are fully defined and you can reference them from anywhere in the project as the generated CodeBehind assembly is global to the Web application.
The other big benefit of WAP is that it makes deployment much easier than stock projects-easier even than stock projects with WDP. The easiest way to do this is to use Explorer and drag-and-drop the files from the old project directly into the WAP project in Solution Explorer. You have to convert all markup pages that contain any CodeBeside code. Once you have copied the files to the new project, use the Convert to Web Application option on the Project menu to convert a single file, a folder, or the entire project to a WAP project.
The conversion goes through each of the stock project pages and fixes up the Page directive, converting the CodeFile attribute to a CodeBehind attribute and creating the. Before you move files over for conversion, make sure your project compiles properly in stock projects as the conversion relies on resolving references and dependencies to figure out how to upgrade them.
Any way that you look at it, compilation in ASP. NET has some complexities and I hope this article has given you some deeper insight into the compilation and deployment process. Usually options are good, but I think in this case the choices can be overwhelming. So watch out for the gotchas and start thinking about these issues early on in the project.
I prefer to use Web Application Projects whenever I can for any serious work. To me, Web Application Projects bring sanity to the Web development process with a predictable and consistent project and compilation mode that was lacking with stock projects. The file-based model using its Edit and Go model of running applications is appealing and make stock projects more easygoing and productive.
And even if you use stock projects and run into a dead end you can easily switch to WAP. My Subscriber Account Advertise Write. Training Home State of. Staffing Home Looking for Staff? Looking for Work? Contact Us. Dark Kimbie. Published in:. Filed under: ASP. The changes in the new project model make it quicker and easier to get a new project up and running or to open an existing project.
Figure 1: Opening and creating projects is much easier in Visual Studio simply by selecting a directory in the file system. Easy on the Surface-Complex Underneath But while the overall operation gets easier, the underlying model used to provide this simplicity is actually very complex and requires a lot of help from ASP.
Deployment Compilation in ASP. While the overall project behavior gets easier, the underlying model used to provide this simplicity is actually very complex and requires a lot of help from ASP.
0コメント