After pre-compiled a ASP.NET web site, I got many files with the names like
App_Web_accountbalance.aspx.dfa151d5.dll
Do you know the rule for the random chars (in bold) above?
Can we fix the random chars?
The reason to fix it is that if we modify AccountBalance.aspx file later and re-compile the web site, can we just replace App_Web_accountbalance.aspx.dfa151d5.dll.
Thank you.
The characters are not random, but more in line with hashing. The purpose is to make the file name unique in the bin folder. Although not advisable, you can replace just certain files to update your website. If you modify AccountBalance.aspx and recompile, you need to replace App_Web_accountbalance.aspx.dfa151d5.dll, accountbalance.aspx.dfa151d5.compiled, and other assemblies and files that your aspx file depends.
I derived the answer from my experience. I was not looking for the file naming rule, but a way to deploy just the assembly of a changed page, same reason as the original post.
The setup:
A web application, deployed non-updateable (updatable=”false” in PrecompileApp.config), pre-compiled assemblies with no fixed names
What I did:
Make the change to the page (say, a.aspx) in development (Visual Studio 2010)
Publish the site with fixed naming to local drive (Build > Publish Web Site, check the box: Use fixed naming and single page assemblies)
Go to the bin folder of the local publish site and look for a.aspx.xxx.compiled
Open the file with Notepad and note any dependency (say, b.aspx, c.master)
Copy all the affected assemblies and the .compiled files to the bin folder in production server. In this example, they are:
a.aspx.xxx.compiled
b.aspx.xxx.compiled
c.master.xxx.compiled
App_Web_a.aspx.xxx.dll
App_Web_b.aspx.xxx.dll
App_Web_c.master.xxx.dll
If you want to know my story, the change was due to a change in a factor in a calculation. The customer knew of the change much earlier, but did not let us know until it became urgent. A proper deployment would involve other parties and much coordination, and would be too late. Plus, I only had the source code of two versions back, and requesting the latest would take time. So, a hot fix on just that calculation change was required as a temporary measure.
1) you can generate single assembly per web application if you want. So when you make a change in web application, you only need to deploy just one dll.
for this, you can check option "Use fixed naming and single page assemblies"
2) Reference from MSDN Article: "The assembly names are generated automatically by the compiler and it is therefore not obvious which assemblies map to which source files. The compiler also creates new names each time it runs, so that the names of assemblies might not be the same after each compilation. In addition, if source files have changed, the compiler might batch up source files differently, meaning that the resulting assemblies do not necessarily represent the same source files. If you are maintaining a deployed Web site and want to update only the assemblies for recent changes, the output from batch compilation can make that job more complicated.
To help you in this situation, aspnet_compiler.exe supports an option specifically designed for packaging and release management: the -fixednames option. This option enables you to create compiler output that has two benefits. The first is that the assemblies produced by the compiler have the same names each time you compile. The second is that the assemblies are based on the same input files each time."
http://msdn.microsoft.com/en-us/library/aa479044.aspx
Related
So I have an ASP.NET VB website that references several other projects (their DLLS are just put in the site's bin folder). I need to update a small piece of code in one of the projects, which I have done and it builds fine. However, when I copy over the new DLL to the website's bin folder it fails to build, and all the Imports statements say "BC40056: Namespace or type specified in the Imports xxx doesn't contain any public member or cannot be found", which results in a ton of errors like "is not defined" . There is no reference to the updated DLL in the website project's properties, but if I put the old version back it's all fine.
The project was copied from a server and the vbproj file contained references to other DLLs, but the HintPaths were a mixture of mapped drives and ..\..\..\. I've updated these so that they're all the full server location path, but this has made no difference. I tried adding the project to the same solution as the website and added a reference to the project instead, but this also made no difference.
I've done plenty of Googling but have yet to find a solution. Any help would be very welcome!
A few things
You don't want to just "place" the .dll's in the bin folder. One big reason is that when you do a "clean" project, the bin folder is deleted. So, anytime you do a clean project, what is in the bin folder is cleaned out. And a developer will often do a clean project if some kind of problem is occuring.
I would place those files in some folder in the project. (create a folder, or if its only one or two .dll's, then place them in the root of the project). At compile time, the .dll's will be copied to the bin folder. And if you using web deployment, then you can choose to have the .dll's all combined into one .dll. So, once again, you can see it makes little sense to place the .dll's in the bin folder, since during a build, they will not be required, and as noted, the resulting bin folder can and will as a "regular" development process be re-created (emptied out). I seen a good number of projects in which the developer did place the .dll in the bin folder (because they did not know where else to place the .dll's, and that was seemly the only place that the application worked. But, during a web build + deployment to the production server, those .dll's can be left behind - they not be copied to the final "deployment" build. (I'm basic saying don't do this!!).
You can also consider just creating folder called "packages" in the root. This is where all the nuget packages are placed. So, some folder for those .dll's is the idea here.
The other big issue? Well, just dropping some .dll's in some place does NOT give you the developer all the methods and properties of those .dll's when writing code (we are assuming these are managed code - not win x32 .dll's).
So, without adding a reference to that assembly, then I can't see how the project will even compile correctly, and how syntax checking, and general use of the assembly will ever work during the development process (so VERY perplexed that you don't have references to those .dll's - that as a general rule can't work).
Now, to use the assemblies? Yes, you want to add the .dll as a reference to the project.
So, in references, add the .dll as a reference.
And then in the property sheet for the refence? Make sure you have the "copy local" set = true.
eg this:
So, above is GhostScript.net reference. (a open source library to manipulate pdf's).
Note the long path name for the .dll location. But, MOST important is the copy local setting = true. This means during a compile and build (which as noted can clean out the bin folder), then the .dll will be output to the final build in the bin folder.
So, I can't see how you can compile anything without an actual reference to the .dll. That is quite much assumed and a given - else I see no way how your project can compile under any circumstances.
So, referance the .dll, and that should allow use of the class(s) and objects, and enable your code to compile. And make sure the copy local = true, as that is the process that will copy + place the .dll in the final output (bin) folder when you compile.
So it turns out that the project for the DLL I was trying to reference had the Target CPU set to x64. Changing this this to 'AnyCPU' then allowed me to reference it.
This post gave me the answer: Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)
I have a website with huge number of pages, i keep pre-compiled version (with fixed naming) on production server.
Every time i make any change on my code i have to Publish the whole website just for a small change.
It takes about an hour to get the website published before i can deploy my changes to production server.
Is there a way to publish only a batch of pages so that the Publish process is faster?
Is there any other option to save the publishing time?
NOTE: By publishing I mean pre-compiling
Any suggestions are welcome.
If you're modifying only the html tags (nto the server side tags) or css, you can deploy only the part you changed.
If it's compiled code you got no choice.
I think you might have to ask your self why it's taking an hour to publish your web site ? Is your compilation time that much long ? .
One method to reduce the compile time, and size of a web-site project is to split your website into several smaller and more maintainable sites.
You can still deploy these separate publishes together in production.
References to pages from other projects work perfectly. All your pages within the same application on IIS will share the same session. So to an end user, this will still appear to be one website.
Since you reduce the work to be done while publishing any given module publishes will be faster. Divide your modules as per what you see as a suitable batch.
You must be aware of this, but I will say it just for completion. When you publish a website you get the option,Use fixed naming and single page assemblies. Select this to have a different dll for each page in your bin directory. You only need to upload the pages and corresponding dlls where you made changes. If upload time is a concern, this will take care of it.
Microsoft doesn't really have an idea of "pre-compiling" if you notice your pages have 3 components to them, the *.designer, *.aspx *.cs. The *.cs all needs to be compiled into a *.dll to be deployed to your website. Traditionally there are two types of executables, exe's and dll's. Asp.Net websites are compiled into a dll for all the code behinds that run on the server. Microsoft does not have a way to "half" compile a dll and then merge it with the other half you haven't changed.
If your website is taking that long, to compile & deploy. I would suggest you have more of an architecture problem then a code problem. Where I work our main website is 3,000,000+ lines of code, to accomplish everything the user needs to do and does. We don't take an hour to deploy. however what we have done is broken our business logic up into a number of dll's over 100 dll's and our website project in and of it self is just the aspx and the bare bones code behind to drive the flow through to our business logic. This allows us to alter x number dll's with our changes to support a new feature, We don't have to deploy all 100 dll's every time just the ones that have changed, that's the nature of dll's. if our business logic was 100% contained in our website project, then our compile, deployment would be significantly longer.
You want to consider refactoring your code into dll's. Another option if you're not married to the ASPX/ASP.NET solution is to consider an ASP/MVC.NET solution. I would consider refactoring your site. If it takes that long there's some serious issues, even if you could break Data access into a separate dll, then you wouldn't have to constantly compile & deploy the dll which handles your data access, every time you changed the website, only when you changed the Data access layer as well.
As previous posts mention, you cannot do this in an automatic fashion, but you could manually deploy your files if you want to reduce your publishing time.
When publishing a website, all code files for your site are compiled into a single .dll file in the website bin folder and all .aspx files are be deployed to their relevant paths.
To update the site manually, simply build the website on your local machine to create an updated .dll and overwrite the .dll in the bin folder on the production server. If the source/HTML has been modified on any of your actual pages/.aspx files then you will also need to copy them over.
Steps:
Build website locally
Overwrite production server .dll with locally built .dll
Copy any .aspx pages to production server where HTML/Source modified
Very simple.
Have all the HTML content stored in separate files to the code. A database would be an excellent idea. All one would have to do to change some text or swap an image would be to go into the database or file for that content and change a few tags. I recommend MySQL.
:)
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'm currently working on an ASP.NET project with multiple developers using Subversion for code distribution, but it's quite frankly totally messed up at the moment. The person who set up the Subversion repository have included config files specific to their computer, bin\* directories, and other such things.
I, being the guy who has to check out this repository and get it to run on my computer, am pretty frustrated by this since it's taken me a while to sort it all out to get it to compile at all. Now I'm thinking about writing a document for Subversion guidelines to send to the technical leader at my company so that we can get the process standardized and avoid these kinds of problems.
What I'm looking for is input on the guidelines. Here's the start for them, and hopefully we can make something good out of it:
The file structure should be set up to have third-party libraries checked in outside the build output directories (since they won't be included in the repository.) The name of this directory should be "Libraries".
No machine-specific files should be included in Subversion. Therefore, only a template of Web.config is checked in, which is customized by the developers to suit their machine. This behavior is included in Visual Studio 2010 by default and the individual configuration files (Web.Local.config) automatically have the template (Web.config) applied. The local configuration file still shouldn't be included in Subversion though, so long as it applies for a specific machine.
Solution and project files must not contain any absolute paths.
An ignore list should be set up. Start with:
'
*.user
obj
'
Example file structure for an ASP.NET 2.0 web site with a class library specific to the web site and a third-party library:
'
/trunk/
Libraries/
ThirdParty.dll
MyClassLibrary/
bin/ [Ignore]
obj/ [Ignore]
Properties/
AssemblyInfo.cs
SomeClass.cs
MyClassLibrary.csproj
- Holds references to third-party libraries. For example:
../Libraries/ThirdParty.dll
MyWebApplication/
bin/
ThirdParty.dll [Ignore; copied by build process]
ThirdParty.dll.refresh
- Contains "../Libraries/ThirdParty.dll"
Default.aspx
Default.aspx.cs
Web.config [Ignore]
Web.config.template
MySolution.sln
- Holds list of projects.
- Has reference information for projects.
'
An alternative to using Web.config.template would be to include a Local.config file from Web.config, but this might be less flexible.
When using a Web Application project rather than a Web Site project, the references will be stored in the project file instead of in .refresh files, so the bin/ folder will be ignored.
Can someone see errors in the above suggestions? Is something missing? Does anyone have suggestions for the ignore list? I just started with a couple of entries for now.
I think that you are a good step on the way. But why not put an ignore on the entire bin folder in /MyWebApplication, instead of the files? You wouldn't add your build output to subversion would you? I would definately consider that a bad practice.
Also, if possible, you could add the web.config file to subversion, but in the element reference a new file with appSettings: for example
<appSettings file="local.config">
Then have the local.config file be ignored by svn. That is how I always operate.
But of course that only works if every configurable parameter is in the appSettings (one of the reasons why I dislike the provider model, because all the providers need to get connection strings from a connectionString element, and you cannot reconfigure them to take a connection string from appSettings)
Edit: troethom enlightened me and pointed out, that you can also override the connectionString configuration settings in a separate file
<connectionStrings configSource="ConnectionStrings.config"/>.
So the thing that I would do is place the actual web.config file under subversion control, but let those other files that override the settings locally be ignored by svn.
You should add the .refresh files; not the real DLLs.
The Visual Studio project system sends a list of files that should be added to source control to SCC Providers. AnkhSVN is a Subversion SCC provider that uses this information to suggest adding these files (and not the other files).
VisualSVN and other Subversion clients that only look at file extensions don't get this information from ASP.Net.
(Note: if you remove the .refresh file, Visual Studio will add the DLL to the list of files that should be committed)
As part of improvements to our build process, we are currently debating whether we should have separate project/solution files on our CI production environment from our local development environments.
The reason this has come about is because of reference problems we experienced in our previous project. On a frequent basis people would mistakenly add a reference to an assembly in the wrong location, which would mean it would work okay on their local environment, but might break on someone else's or on the build machine.
Also, the reference paths are in the csproj.user files which means these must be committed to source control, so everyone has to share these same settings.
So we are thinking about having separate projects and solutions on our CI server, so that when we do a build it uses these projects rather than local development ones.
It has obvious drawbacks such as an overhead to maintaining these separate files and the associated process that would need to be defined and followed, but it has benefits in that we would be in more control over EXACTLY what happens in the production environment.
What I haven't been able to find is anything on this subject - can't believe we are the only people to think about this - so all thoughts are welcome.
I know it's anachronistic. But the single best way I've found to handle the references issue is to have a folder mapped to a drive letter such as R: and then all projects build into or copy output into that folder also. Then all references are R:\SomeFile.dll etc. This gets you around the problem that sometimes references are added by absolute path and sometimes they are added relatively. (there's something to do with "HintPath" which I can't really remember)
The nice thing then, is that you can still use the same solution files on your build server. Which to be honest is an absolute must as you lose the certainty that what is being built on the dev machine is the same as on the build server otherwise.
In our largest project (a system comprising of many applications) we have the following structure
/3rdPartyAssemblies /App1 /App2 /App3 /.....
All external assemblies are added to 3rdPartyAssemblies/Vendor/Version/...
We have a CoreBuild.sln file which acts as an MSBuild script for all of the assemblies that are shared to ensure building in dependancy order (ie, make sure App1.Interfaces is built before App2 as App2 has a reference to App1.Interfaces).
All inter-application references target the /bin folder (we don't use bin/debug and bin/release, just bin, this way the references remain the same and we just change the release configuration depending on the build target).
Cruise Control builds the core solution for any dependencies before building any other app, and because the 3rdPartAssemblies folder is present on the server we ensure developer machines and build server have the same development layout.
Usually, you would be creating Build projects/scripts in some form or another for your Production, and so putting together another Solution file doesn't come in the picture.
It would be easier to train everyone to use project references, and create a directory under the project file structure for external assembly references. This way everyone follows the same environment.
We have changed our project structure (making use of SVN Externals) where each project is now completely self-contained. That is, any references never go outwith the project directory (for example, if Project A references ASM X, then ASM X exists within a subfolder of ProjectA)
I suspect that this should go some way towards helping solve some of our problems, but I can still see some advantages of having more control over the build projects.
#David - believe it or not this is what we actually have just now, and yet it's still causing us problems!
We're making some changes though, which are forced upon us due to moving to TeamCity and multiple build agents - so we can't have references to directories outwith the current project, as I've mentioned in my previous answer.
Look at the Externals section of this link to see what I mean - http://www.dummzeuch.de/delphi/subversion/english.html
I would strongly recommend against this.
Reference paths aren't only stored in the .user file. A hint path is stored in the project file itself. You should never have to check a .user file into source control.
Let there be one set of (okay, possibly versioned) solution/project files which all developers use, and the Release configurations of which are what you're ultimately building in production. Having separate project files is going to cause confusion down the road, when some project setting is tweaked, not carried across, and slipped into production.
You might also check this out:
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx
http://bytes.com/forum/thread268546.html