Working on an intranet where we have about 20 different web apps - some .net, some classic asp.
Currently each .net app is its own solution. There are advantages to this - we can build & deploy just one app, without affecting other apps, and all the apps share a session - but we can't use master pages, and there are real challenges using localization resources, shared css and js, etc. Build & deployment is done completely manually, which is a real problem.
I'm trying to set up a structure that will allow us to take advantage of VS2008 features, but still have the ability to update one app without affecting the others while still using features like master pages and localization resources, and sharing session between apps (so we can't set up virtual directories for each app).
If I set up single solution that looks like:
/Root
- App_GlobalResources/
- shared
-- masterpages/
-- css/
- App1/
- App2/
...
- AppN/
..
- ClassicASP1/
then the problem is that the build just produces a single DLL (Root.dll) - this will simply not scale to 20+ apps, all of which have different development cycles.
Is it possible (using nant, or some other build tool) to build multiple DLLs? In this case, I'd like to end up with Root.dll (contains the global resources at least) and App1.dll and App2.dll.
Any other suggestions or references I should look at?
I'm not sure you can do what you want to do, sadly. VS tends to make one DLL per unique project (not solution), and it appears you have just one project, so hence, one DLL.
I'd suggest you keep one project (csproj) per application, but use NANT to build them all (ie, one at a time, together, in order), and package them all up for deployment. That way you can do a single point deployment, but still keep the apps seperate.
I'm surprised you can't use master pages in the sub-folders. You'd need to replicate them for each AppN folder, but again - NANT could be used to pull those in from a common place when you build your deployment package.
Writing a build and deployment script takes a while to get right, but I've found that once it's done, it pays for itself very quickly - even if the only payment is your sanity!
There is a solution to this problem. In short, it entails creating a Web Site Project (which can have the masterpage and whatnot) and several subdirectories, each containing a web project. In the main web project you exclude the subdirs from the project. You then add the project files to the solution. This (updated) link tells you all about it.
-Edoode
I would advise using MSBuild instead of Nant. It is more native to visual studio.
Related
Our development team has used aspnet_compiler as part of our build process for years to verify our website build. I have noticed that when the process encounters a precompile error, it immediately shuts down. Sometimes, if you fix the issue and restart, it will fail again with another unrelated error that actually existed the first time. I am just wondering if there is a way for it to not "die" and continue the precompile and then list ALL errors that it finds so we don't have to do the iterative process of fixing the errors one at a time.
I have looked at this documentation: https://learn.microsoft.com/en-us/visualstudio/msbuild/aspnetcompiler-task?view=vs-2019 but nothing there seems like it supplies what I am looking for.
do you mean that VS shutdowns, or the external command line build process shuts down? One real problem area is the .net folder called app_code. While you can do a build->compile?
You note that code in that folder does NOT get compiled when you do this. It is only compiled by the build process. Even during debugging, you note that compile errors are not seen (or caught) unless you run (try) the site. As a result? I don't use that folder anymore. The 2nd huge problem is royslen editor code. I have started using that ability's for strings to span multiple lines in - really nice for in-line sql.
However, I find then if you let the web site build, it does NOT support + see and allow such Rosylen formatted code. (so upon run of the site, I get errors). (this might well be due to the web site running IIS 2016 - too old for that new code formatting support (at least in vb.net it is).
So, all I did was create my OWN folder for code and NOT use the .net one ().
Note that you create the folder, but remember for EACH code module, or class you drop into that folder? You have to individual set each to be compiled. (it is the default), but be careful if you import code via add. So you see (and want) to use this option:
So, I of course don't want the source included - and I don't require that since this is a web applicaiton vs a web site.
Thus, I don't get/see/have any runtime compile of my code by the web site compiler process - it all done during the build and even debug process in VS.
And then their is the build for a web site publish. Thus during a deploy build (and publish), I don't get any surprises either.
In other words, the GREAT advantange of a web site applcation is you don't let the web site comile code for you.
You do have to mark the code module as per above.
As a result, this folder behaves like any web form with code behind. The standard debug and build process during development will thus compile all my code - and catach errors.
If you use the built in (and special) folder app_code, then such code only compiles WHEN you run the site, and worse it is the web site that does this compile - NOT VS.
(but of course you publish build process ALSO does this compile!!!).
I need (want) a regular build + compile during the development process to catch and compile all that code (else debugging, and worse compiling means you only can find out issues at web site run time - and that's way too late for my tastes).
So, I don't bother with app_code anymore at all. Now I am lucky, since I am creating (using) a web site application, as opposed to a asp.net web site. (and yes, there is a massive difference).
Asp.net web site = each page and code behind will compile on demand. This choice is perferred for two big reasons:
First, you can update one web page (and code)- deploy that one web page + code. The web server will figure this out - and re-compile that one page on demand. This makes updates and maintains of the site OH SO VERY much easier.
And it also means in most cases that the whole site can be published to a sub-site folder on the hosted web server. And in fact most really cheap low cost web site hosting MUST use this option (web site applications in most cases can't be published to those lower cost .net hosting sites). (thus use web sites, not web site applications).
However, if you lucky, and you have FULL use of IIS and a server dedicated to JUST running your web site? Well, then you are MUCH MUCH better off to go with a aps.net web site application. And this also means you can say setup custom logon providers, and also configure things like re-direction or things like a custom web handier. In effect, this choice means that you as a developer not only have full use of the base starting page, but can directly change/configure the web server to your liking. This includes the base web config.
This choice is often not avaible on lower cost hosting plans. it requires that you have full IIS services, and IIS services is running your whole site, and the base starting page is your site. (you can publish to root on web hosting, but you still using THEIR EXISTING copy of IIS services, and you can't control things like creating a custom authneticaion (logon) provider. And you also can't create re-directs (custom one).
However, in both cases/choices app_code folder behaves like a compile on demand folder. Thus bugs and issues in that folder will thus not be found until you run the web site, or do a full deploy that then does the full site build. and as noted, you can't use Rosylen eiditor souce code features, since the web compiler might be a few verisons old. You be running the SAME .net version, but the older compiler does not support source code formatting with the new Rosylen editor features.
Since a web site application will compile everything (whole site) in your application down to a single .dll (and of course referenced libraries), then then you don't have on-demand occurring by the web site compiler (after you deploy). Of course the publish wizard does have options to combine all those .dll's into one - not a big deal either way.
So, the one exception is app_code. So I just stopped using it, and I see little reason to use that special .net folder anyway.
So, it was never clear if VS is shutting down, or your build process is seeing errors not being caught during the regular development cycle with VS - if this is your issue, then the above approach should solve the problem for you.
I have a big ASP.NET application (legacy) which actually (functionally) is composed from two portals. So I need to split it to two separate applications, to ease the development on each of them.
Of course there are shared features between the two. Some of them are in DAL and BL, and that is not an issue - all that code was separate din separate projects, which made up assemblies that are to be referenced in both apps.
But the problem is with some pages, lot of user controls, some css and javascript files, which are shared between the two "portals" (applications).
I'd like to ask for some advice on how to handle them. My main concern is to avoid duplication, so ideally they should stay in a single place, and be used by both apps.
First I tried was to add files from one project to the other as linked files. While this works for code file (they get built into the project they are linked to), it doesn't for aspx / ascx or css / javascript / images. It does if I publish first (if marked as content, they get copied during publish), but I can't do this all the time during development, and such files are not found when app is debugged / run from source code (sincve, obvious the linked files are not actually available in app file tree, when one is looking for any of them.
Another thought was to create pre-build event, and in that to copy all shared files from a common location.
e.g. I create a project Common and put there all files that are shared between applications, organized on folders, and on pre-build I perform an xcopy.
And another thoughts is to make all shared files part of a SVN repository which I reference with svn:external, in both projects.
But all looks to my little cumbersome. Does anyone had similar situation? How did you handled it?
Any advice on any of my suggestions?
You have, at least, two options :
sharing through virtual directories : https://stackoverflow.com/a/13724316/1236044
create user control libraries : https://stackoverflow.com/a/640526/1236044
The virtual directories approach seems straightforward for ressources like css, js, images.
I also tend to like it for sharing user controls.
The library approach should need more work, but would ensure better reusability of the controls on the long run.
I had an identical problem this week with css and javascript files triplicated across three legacy projects.
I removed the files from two of the projects and replaced them with linked files to the first project, but when I ran the website I got 404 errors for css & javascript files missing in the pages belonging to the two projects.
So I simply added the nuget package 'MSBuild.WebApplication.CopyContentLinkedFiles' to my solution and everything worked fine - the css and javascript files were deployed fine for the two projects and my 404 errors disappeared.
I didn't have any shared .aspx / .ascx files, but I would imagine it will work for them too.
See also this question / answer.
I am working to setup a build server using Team City to build and deploy asp.net web applications to a staging site with transformed web.configs automatically. Everything is working except that the code that ends up on the website (the aspx files) have the HTML in them when you open them in notepad.
Before all of this I was using web deployment projects with websites, and the code was compiled. If you opened one after it was deployed, it said it was a marker file.
I have tried some tutorials on how this process should work, but the code always ends up in an editable state (the html).
My question is:
What do I need to do to get MSBUILD from the command line to ultimately have precompiled code on the webs server?
Any suggestions, links, pointers, or ideas would be very helpful to me.
You need to invoke the aspnet_compiler tool to do this. There are some limitations or complications depending on exactly what you need to do for things like strong-naming. The MSDN article here has pointers.
I used to have MSBuild project steps that did this, but we decided to drop precompiling because our clients want to integrate our product into their internal portals, and precompiling made things complicated for them.
Are you using MS Web Deploy? I use it regularly for automated deployments from my Team City Build server to dev, staging, QA, etc. And I'm transforming configurations as well.
If you want to check out this alternative you can follow the excellent guide by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
For example how this site is organized?
What i do not understand is what they upload to the Microsoft server?
I have created, with Visual studio, a very small web-page and i have to upload the whole site, even after the smallest change...
The usual approach is to replace everything with xcopy or the publish function in visual-studio, and in some cases replacing everything is the only approach - for example if you're using the web-application project model everything gets packaged into a single assembly and there you go - even to apply a small change you'll have to re-deploy the whole thing.
An alternative to this could be the Website model in visual studio, using which you should be able to deploy single code files on your server and they should be picked-up if you re-start the website from the IIS management tool. This model - in fact - works in a different way compared to the web-application project model. It's just a bunch of code files that will be dynamically compiled by the ASP.NET runtime.
Even if possible though - I wouldn't suggest the approach of deploying single files - as this is easily error prone (you deploy the code-behind and could easily forget to deploy the aspx counterpart, or similar). Unless you're delpoying Gigs of stuff over slow-networks, redeploying the whole thing is always the safest bet.
Have a look at this and this interesting links to find out more about website and web-application project models in visual studio.
It really depends a lot on how you're building your app.
If you're in VS and you're doing an ASP.Net site, then you can either do it as a Website Project, or as a Web Application project.
in the former case, your files will remain as aspx and .aspx.cs files and you xcopy (or FTP) whichever files change. if you want logic that's outside the scope of a single page, you'll either create a separate class library project or else use the App_code directory.
In the latter case, you'll compile all the logic into one or more .dll files that get copied to your site's /bin directory, and any number of aspx files that can either stay as such or be embedded (recommend leaving them as aspx files). Again, if an aspx file changes, you just movethe one that changed, if anything in the dll changes, you replace a whole dll.
All that said, a huge chunk of what's on the site you posted is probably being pulled out of the database. Most sites now dont' have content on pages, they just have organizational (view) logic on paes, and have other classes which fetch the actual content out of a database to serve up. This allows greater reuse and means that the 4,000 pages (number chosen at random) on MSDN don't have to be each coded individually as an HTML page.
After Googling i think, the check-box Use fixed naming and single page assemblies in the publish Website form of the Visual studio, is the right choice.
Although it might slow things down...