The dynamic compile-on-the fly approach seems to fall outside the capacity for the typical tools which would extract this kind of information. I know I may be better off converting to a Web Application, BUT I would like to ask how it could be done in the case of a Web Site Project.
The aspnet_compiler can still leave you with a boatload of assemblies to scan. You can chase it with aspnet_merge, or use a Web Deployment Project to run the compiler and merge utility for you. WDP can give you a single assembly for the entire web site.
You could always use the aspnet_compiler and then scan for dependencies on the compiled assemblies.
Related
I mean when I publish my web application asp.net publisher generate one assembly why ? I like to have different assembly. is it possible ?
While publishing, Asp.net compiles all your code files into a single assembly and uploads it with other UI files i.e .aspx or .cshtml. It does so to make your application precomplied for faster performance. Every .net project has a single assembly. If you want to factor your assembly then make different projects according to your liking for getting different dlls.
For further information you visit this video link Deploying A Web Application Using Visual Studio 2010 Web Deployment Tool
If it is web application project you can have multiple class libraries and those will be complied in to several assemblies.
That will require a good amount of work, so I hope that you have a good reason for it, but here is a guide to get you started:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;307467
Q:
Recently , i face some problems, i have a dll common among a lot of applications,and any change to this dll require to build it, copy and paste it in each bin folder of these applications ,and add the new reference so i decided to convert this dll to a web service in stead to overcome this overload..
I make a web service application contains set of web services(mapping to each class).
I face some problems here:
In the original dll, there are
classes use methods exist in other
classes in the same dll, and i face problems when i
tried to use web service methods in
other web service class.how to fix
this problem.
In the original dll there are set of
static classes with static
methods.how to make the equivalent in
my web service application.
Any overload method cause a problem
in my web service.
When using Dictionary<string, string>
as a parameter in my method.
Note:the original dll contains the connections to the data base. Is converting it to web service is the optimum solution?which one is faster in my case a web service or the dll?Should i tend to WCF instead of?
thanks in advance.
In my applications I usually have all related projects in the same solution. But when I need to use projects across applications I replace the project for a dll reference.
Because I use Subversion I solve the problem of copying the dll by adding an external property do my libs folder, referencing the build of the dll.
If the external dll is updated very often than you probably need a continuous integration system to handle that for you.
I usually add project reference and keep all my projects under single solution, so I do not have file copy issue. You might be missing project reference, instead you could have used assembly reference. Verify that first.
First advice, don't create a web service if you don't know what it is and how it can be used. People tend to think everything is a web service since creating a web service in WCF is so easy by using visual studio tools. Since you ask like converting DLL to a web service, I assume that you are beginning with learning web service.
All you need is kind of continues integration system otherwise a simple build system which does the build for you and it copies the files wherever depended applications folder. Hence you can save your time for coping files manually. When you do this, you will not have any of those 4 problems you have mentioned.
If you are lazy enough to learn the build system, simply write a batch file that would copy the files for you. I do have batch files which does xcopy files.
I've heard recently that you can precompile Web Application projects. My question is how?
Right now, when I do a publish for my web application and select only files needed to run this application I get it published but it still has all my ASPX pages and it will still only JIT compile the pages. How do I make it so that all of the ASPX pages are precompiled before putting them on the server?
You can download a project template called a Web Deployment Project (WDP) (VS2008 version here), which enhances the build and deployment features of Visual Studio. This basically wraps features of aspnet_compile.exe, but allows you to do this visually as part of your overall solution.
Besides pre-compilation, it also allows you do a number of interesting things, like config file replacement (great for deploying to different environments) and setting how your assemblies are built (per-page, per-site, etc.).
Two good Scott Guthrie blogs about this project type:
announcement of the tool for VS2008:
http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx
basic walk-through of the tool
(VS2005 version, but it's basically
the same in VS2008):
http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx
I've used this project type for some VS2005 and VS2008 projects and it's invaluable (especially for those legacy web site projects!!).
I didn't know this was also in the MSDN library, but here's a nice article in MSDN for WDP's.
I hope this helps!
EDIT:
WDP's exist for VS2005 and VS2010 also.
Unfortunately, the way to do this isn't spectacular. You would have to "deploy" the solution locally, then move it, or just compile it on the server where it will go. Either way uses aspnet_compiler.exe. See http://msdn.microsoft.com/en-us/library/ms227976%28v=VS.90%29.aspx for more details.
When you publish the site, uncheck the option that says "Allow this precompiled site to be updateable".
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change
I am trying to a create an installer for my web application. My solution contains several projects. They include:
Class library project (referenced by the web application)
Web Application
Windows Service
Web Services project
Database project (execute update script)
I also have an unmanaged dll (crystal reports) in my web application project, so I might have to do some editing of the registry.
I ideally want to be able to use a web setup project to install the whole solution. Can this be done? Is there a better method/solution?
The short answer is "Yes" it can be done.
Other better solution? Well, I'm not a huge fan of VS.NET's installer/setup, can be kind of bulky, 3rd parties could be better at a price. Having said that, it should be able to satisfy your requirements.