I am trying to understand how the licensing works in ASP.NET.
There is licx file, App_Licenses.dll file. And then there is a difference between how the licensing works for a WebSite and a WebApp project.
Any insight into these would be of great help.
Links, explanation are most welcome.
Thanks.
I'm not sure of any differences between WebSite and WebApp, but with a licx file, it is compiled into the app_Licenses.dll file. If its not generating for you - you can right click on your licx file and regenerate the dll.
As per MS -
http://connect.microsoft.com/VisualStudio/feedback/details/499908/app-license-dll-can-not-be-generated-automatically-in-asp-net-website
In a web application project, manually copy the .lic file to /bin folder. In a Website, this is done automatically.
At this pointm refresh the designer or rerun the project and the licensed control should work as expected.
Note: App_LICENSES.dll isn't required in a WAP. In Websites, App_LICENSES.dll is generated to contain the LICX as an embedded resource. In WAP, there is a project assembly which contains the embedded LICX resource, so a separate DLL is not necessary
Related
In the old asp.net project, there is a published .cs file in one of the folders. When I update the site, I update the .dll files, but this file is never updated. When I delete this .cs, the site does not work. How do I delete this file?
Are you using a asp.net web site applcation to publish, or are you using a asp.net web site?
As a general rule, if you using asp.net web site applcation, then the source code files are NOT required to be up-loaded.
However, you left out one big detail. Where is that cs file? While a asp.net web site will attempt and does pre-compile all code, ONE BIG exception to this rule exists.
That is the folder app_code. That folder is in fact compiled by IIS, and as a result, if that file is in that folder, it will have to be included in your publish.
In fact, when I started using the newer Roslyn compiler (I liked it VERY much for allowing me to have longer free text such as SQL in the code as strings).
However, IIS did not and does not have Roslyn compile by default. And my code was breaking.
So, as a result, I simple create my own folder called MyCode. And you could do the same. Note that each code module (vb.net) or static class for your general shared code routines do have to be marked manually as to compile.
eg this:
So, if your .cs file is in app_code, then you can move it out, drop it into a folder you create, and set the file build action to compile, and of course do not copy.
However, and this is a HUGE big "if". If your deployment model is web site as opposed to web site applcation, then this will not work, since IIS is doing your compile after deployment, as opposed to pre-compiling the code BEFORE deployment.
So, you are in luck if your .cs file is (or was) in app_code, since then as noted, you can move that out of app_code, and in properties set the file to be compiled, but not deployed. This as noted will only work if you deploying as a asp.net web site applcation as opposed to a asp.net web site.
I'm a real newbie for ASP.NET web development, having a background in Java. A friend has an ASP.NET 3.0 deployment running on IIS. He can't find the original project files created in Visual Studio 2008 and has asked me to give him a hand.
Is it possible to recreate the project from the deployment on IIS? I see lots of ASPX and and CS files so in the inetpub[domain]\httpdocs directory.
I don't see the .SLN file. I assume that's what he needs. Would it be a real chore to rebuild? Are there any assets or source files that won't be deployed to ISS that I'd need to recreate?
Thanks
Re-creating the soloution/project files is (potentially) a small part of the recovery. Do you see any .aspx.cs or .aspx.vb files on the web server? If not, you'll need to extract the code from the code for each .aspx file from the DDL's in the web site's /bin folder. You can reverse engineer any .Net code quite easyily luckily with reflector, however all comments will be lost.
If you have the aspx and the cs files, you are in business: all you need to do is create a new Web Project in Visual Studio and select "Add Existing Files". You would then select all your aspx pages only and the cs files should get automatically imported for you.
Obviously, as anything, you'd probably have some references missing and what not, but shouldn't be incredibly painful to fix all those issues.
If it's a compiled web application project the code will be in a compiled assembly in the bin folder. This can be decompiled with .NET reflector. The source will be readable but not as original.
If it's a website project you're in luck. The code files will be in the website structure (*.aspx.cs or *.aspx.vb). These will constitute pretty much all of the assets you need to recreate the site in Visual Studio. Creating a project and solution file to manage these in VS will be the easy bit.
i have publish my website. using publish website in vs 2008.
Now i want to update a single file.
So do i need to recompile the whole web-site and upload it to the server again, or i will just publish this single file and upload it to the server.
if i can compile a single file then how to do it, also how to update it to the server?
Depends on whether your web project is a web application project or web site project. If its a web site, then you can just copy your updated file to the server and ASP.NET will recompile it for you.
If your web project is a web application project, and you made changes to the code behind, you'll need to recompile the project, and redeploy the DLL.
Also, if you're just updating an ASPX page (not the code behind, ASPX.cs), you should be able to deploy it without compiling.
If you frequently update your website, I recommend to Check
Use fixed naming and single page assemblies checkbox.
This will generate seperate DLL for each code behind page,
Although you have to compile full project but you can upload only relevant file.
This is very helpful in case if many people are working in single project, everybody can change in their respective .cs file and publish their .cs file's DLL , this will not affect other people's DLL and thus functionlity will not break, unless DLL's or codebehind clashes with each other.
I want to update a class library (a single DLL file) in a production web application. This web app is pre-compiled (published). I read an answer on StackOverflow (sorry, can't seem to find it anymore because the Search function does not work very well), that led me to believe that I could just paste the new DLL in the bin folder and it would be picked up without problems (this would cause the WP to recycle, which is fine with me because we do not use InProc session state).
However, when I tried this, my site blows up and gives a FileLoadException saying that the assembly manifest definition does not match the assembly reference. What in the world is this?! Updating the DLL in Visual Studio and re-deploying the entire site works just fine, but it is a huge pain in the rear. What is the point of having a separate DLL if you have to re-deploy the entire site to implement any changes?
Here's the question: How can I update a DLL on a production web site without breaking the app and without re-deploying all of the files?
The thing to remember is that there are web sites and web applications as far as Visual Studio and ASPNET is considered.
Web Sites typically have all of the aspx and vb files published to the live server and ASPNET Worker Process recompiles the app every time before presentation.
On the other end is the web application, where all of your code behind files get compiled down to a single DLL file and you simply deploy your aspx pages and you bin folder with the DLL file to production.
There is also a "hybrid" known as "Precompiled Web Sites" (see the link for the official MSDN overview) where you don't have the single DLL layout of a web application, but all the compile work of the website is done for you. There are several "modes" to this depending on your needs.
It seems to me that your error is caused because your site is set up as a web site with some kind of precompilation in place. Using the pre-compiled model is a little more "strict" in that is assumes certain files/signatures are in place. Having an updated version of the DLL file causes a break since the precompilation wants a name and a version of the file.
If possible, your best bet would be to convert to a web application, since you can add the additional DLLs into production without a problem. Otherwise, take a look at this matrix to see what form of precompilation you need for your application.
Look at this SO post, might be what you are referring to. The located assembly's manifest definition does not match the assembly reference
Have a look at your reference. Does it say "specific version = true" ? Set it to false, republish your app (you have to do it once, because now your app is still looking for an assembly with a specific manifest) and try it again.
I'm using a Web Deployment Project in Visual Studio 2008 in order to prepare my ASP.NET application (ASP.NET web application, not ASP.NET web site) for being copied to several servers. I have to copy the files on local staging servers, on different servers via FTP and sometimes I have to fetch them from customers' servers.
So, it would be nice to have all files for deployment in a compact form without the necessity of doing a lot of comparing between source and destination. Web deployment projects have this nice feature: compile all your aspx and ascx files into a single (additional) assembly.
I somehow found out how to get rid of aspx placeholder files on the server, now I'd like to know if there is a (maybe self-made) way to get rid of these .compiled files.
From Rick Strahl's blog:
The .Compiled file is a marker file
for each page and control in the Web
site and identifies the class used
inside of the assembly. These files
are not optional as they map the ASPX
pages to the appropriate precompiled
classes in the precompiled assemblies.
If you remove the .Compiled file, the
page that it maps will not be able to
execute and you get a nasty execution
error.
Anybody out there with a creative idea, maybe using a module/handler which intercepts the check against the .compiled files in the bin folder?
The .compile file comes from pre-compiling on deployment. So you basically have 3 options:
Keep the .compiled file
Don't pre-compile and deploy source code
Turn this in to a Web Application instead of a Web Site and compile as an assembly
I have run in to the same problem myself. I actually choose #1 in most cases when dealing with deployment of Web Sites, but on the rare occasion when I know I am going to have to maintain the site for an extended period of time, I take the time to upgrade it to a Web Application.
I don't like the .compiled files either, but nobody gets hurt if they're there. So why bother?
You might want to take a look at Virtual Path Providers (KB how to here) in ASP.NET.
Credit for this suggestion must go to Cheeso and his self answered question here:
Can I get “WAR file” type deployment with ASP.NET?
I don't know about the .compiled files, but you could set up your servers to update their files with subversion instead of manually copying the files when you compile.
So you would compile the files using the Web deployment project (not into a single assembly), put them in a repository you created for this purpose, and on each server, just do an svn update to fetch and compare the files automatically.
I know it's not what you asked for directly, but it may be a path to explore.
Add "Exclude Filter" to your deployment project:
In the Deployment Project.
Right Click on Content Files.
Click on "Exclude Filter".
Add "*.Compiled"
click OK.
and thats it.
I remember at the days when I cant do Web Application with VWD Express, I use nant script to compile the project into a single dll and deploy, that would work (so I dont need the full VS to do dll deployment too), so if you really don't want to mess your project to Web Application, maybe this is a path to check too.
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.
If you publish your code as updateable (in publish settings) these files are generated. Uncheck that value and republish. This is an old question I know, but no answers are clearly defined for this here.