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.
Related
Denizens of Stack Overflow, I come before you in hopes of solutions to my current problem, as so many of my questions have been answered by you veritable founts of knowledge. Is there a simple way to create a unit test for an ASP Web Site Project that was already created without requiring the installation of software that requires you to buy them should you wish to continue using them? If there was a way to get the ASP Web Site directory to be treated as a Project, that would solve things very smoothly. There are two methods to accomplish this that might still be viable but that I have given up on are:
Linking the ASP Website Project to a normal Visual Studio Project.
A method I saw online suggested that one could simply drag the ASP.Net Web Site Folder on to a normal VS Project and this would effectively make the Project a copy of the ASP Web Site with all functionality of the Web Site for Unit Testing with the sublime easiness of being able to use Add Reference for the Unit Test Project, so much more simple than what I've encountered with Add Service/Web Reference. On a similar note, there was a website that suggested adding all the content of the ASP Web Site into the Root of a project. Neither of them worked for me, but I might have been made a mistake in my interpretation of the instructions.
Once I gave up trying to get the Unit Test to Add Reference to the ASP Web Site, my next approach was to link a Web Reference to the Unit Test. At first I tried placing the http://localhost(number)/ of the ASP Web Site in the Web Reference URL, but that didn't work. I saw something that mentioned creating an IIS Site for the Unit Test to reference, but I couldn't make much sense of it.
I've been trying to come up with a wsdl file, and to that end I downloaded WCF LOB Adapter 2013. I don't have BizTalk installed, and after the software provided the message that BizTalk needed for BAM to be installed, I decided against downloading further software. BizTalk itself was already about 660 Megabytes, and for something that is easily a fifth the size of the entire Windows 10 Operating System, I thought that BizTalk ought to be able to run without needing additional specialized software.
I recently discovered that .asmx pages happen to show up when I tried to Add a Web Reference. Instead of giving me an error about connectivity, I received an error stemming from how I had duplicate web.config files in the same solution thanks to trying so many different approaches without success and not clearing them out.
I haven't really looked much into MVCs because the tutorials I go through don't really show how you use MVCs to test the existing code of one of the various aspx pages that my company wants to have Unit Tested.
I think I was having success with [this][2] tutorial, but trying to run a asmx file I created gave me the "Not well formed" error, and my Command Prompt doesn't recognize me as administrator, even though Control Panel says I have admin privileges, which seems to be a large impediment to applying the different work-arounds. However, after using "Clean Solution" several times and deleting other projects from the solution, I was able to run the asmx file after all. However, now I'm stuck on the end of the 2nd step where a batch file (.bat) is supposed to be creating a .cs file in the Bin folder from the .asmx page.
I've gotten to where the Visual Studio Developer Command Prompt is okay with both 'wsdl' and 'wsdl.exe' no longer give the:
wsdl/wsdl.exe "is not recognized as an internal or external command, operable program, or batch file" error.
The contents of my batch file are:
wsdl /l:CS /n:WService /out:bin/wsdlWalkthrough.cs
http://localhost/webserv.asmx?wsdl
Since I'm trying to follow the steps of an article old enough to have graduated elementary school, the syntax may easily have changed. Instead, now I get the error:
'http:' is not recognized as an internal or external command, operable
program, or batch file.
I'm going to make this one into a question in and of itself, because this question was if there was a smooth, simple, cost-free way of setting up a Unit Test for an ASP.Net Web Site, not specifically to answer any of my problems, though such would be received with much gratitude.
[Another tutorial][3] might yet provide me a solution, but I'm not going to hold my breath.
UPDATE 2/29/2016
With assistance from Stack Overflow's ever so helpful ChristiFati, I was able to get through Dimitrios Markatos' Creating and Consuming .NET Web Services in 5 Easy Steps which can be found at http://www.sitepoint.com/net-web-services-5-steps-3/ The article may be over a decade old, but it was still by far the easiest method I came across in my week or two of trying to figure out a way to add a reference, or in this case Add Web Reference that I came across. Two things to be careful of though. The first is that if you copy and paste code directly from the tutorial, you might end up with errors because the batch files you make will have an extra newline character, which caused the Developer Command Prompt for VS2012 I was using to run the .bat file to give me the
'http:' is not recognized as an internal or external command, operable
program, or batch file.
error. Thanks again to ChristiFati for pointing that out for me. Similarly, the instructions for Step 3 give you the following code for a second .bat file:
csc /t:library /out:binGetSuppliers.dll binGetSuppliers.cs
/reference:System.dll,System.Data.dll,System.Web.dll, System.Web.Services.dll,System.XML.dll /optimize
Besides eliminating the white-space and newline characters, the above code should probably look more along the lines of:
csc /t:library /out:bin/GetSuppliers.dll bin\GetSuppliers.cs
/reference:System.dll,System.Data.dll,System.Web.dll, System.Web.Services.dll,System.XML.dll /optimize
But aside from that, the tutorial was a gift from God after all the dead ends I had come across. I'm judging my question answered because the critical issue was being able to give my Unit Test a Reference, whether a normal reference or Web Reference. I do not anticipate any more major difficulties and hopefully I will be able to finally proceed to Unit Testing for one of our ASP Web Sites. If not, this post will be edited to describe the newest problem.
Well, this is ridiculous. I'm able to add the Web Reference just fine, but doing so seems to have done diddly-squat for being able to reference the different .cs pages anywhere inside the ASP.NET Web Site. Does anyone have a way to get a Unit Test to be able to reference code/classes within an ASP.NET Web Site?
UPDATE 3/8/2016
There is a somewhat simple solution to the problem in placing all the functionality of your website into a DLL. Once that is done, right-click on the Unit Test project and select Add Reference. The DLL didn't show up on any of the tabs, but I was able to select the appropriate DLL by clicking on Browse.
Still, if there's any other ways to set up Unit Tests from an existing ASP Web Site where such a DLL doesn't exist.
My Visual Studio 2013 Solution
[2]: http: //www.sitepoint.com/net-web-services-5-steps- 2/
[3]: https: //msdn.microsoft.com/en-us/library/ms731835%28v=vs.100%29. aspx
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.
:)
Just read about the possibility to use codefile=somefile.aspx.cs instead of codebehind=somefile.aspx.cs in web application projects (described here). Obviously this causes the file the compile only when loading the page, it's not precompiled anymore (right?).
Are there any negative or unexpected side-effects by using codefile instead of codebehind in a web application project?
I think you could run into problems for supportability if your site isn't all one or the other. (CodeFile or CodeBehind)
i.e. If you're trying to figure out a problem on your production site that your error handling tells you is within a certain file or namespace, you'll have to stop to examine every file and control that you are supporting before troubleshooting to see if the page is running as part of the compiled assembly or running from the codebehind on the site.
You could also run into conflicting or missing namespaces if you try to have a mixed environment.
Pros as I see it for CodeFile:
Your production source code can sit on your production website. If the code is all compiled in a DLL in your bin directory, there is no absolute guarantee that the code you have on your development environment or source control is what's out there. (Sure it SHOULD be, but if everything was always as it should be, many of us wouldn't have jobs fixing other people's code!)
For updates, you only have to push out single files, not an entire assembly.
You would be able to have developments in progress on other pages that you don't need to back out before recompiling and publishing to production.
Cons:
Since you're not pushing out a compiled assembly, you may have errors within individual files, that won't necessarily be caught unless someone visits each specific page or if you are sure to compile before deploying.
You may have conflicting namespaces in codefiles that may never be caught and could cause confusion or errors.
Performance issues for dynamic compilation
Just wondering what is the best option for deploying an ASP.Net Website.At the moment I just place the code in a folder on server and create a virtual directory on IIS referring to this folder. Then I open the website in VS2008 on the server and build it.Though it works fine for me,I am not sure if I am following the best approach for deployment or not.
Thanks.
There's a wealth of opinion on this across the internet and it is all opinion. To an extent it's down to you and your team (if you have one), if your approach is working for you then I don't see any huge reason to change but I would suggest that you at least have a staging site where you can deploy the code for user testing before it's deployed to production.
That said, running VS on the server isn't great (and means you need another VS license so could be a waste) and as VS includes a Publish option anyway, it's rather redundant. I use publish for the smaller sites and it works a fine.
Publish from inside VS is a pretty powerful tool as it lets you do web.config substitution. Check out the Hanselman talk Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong
You have several options which are preferable to running Studio on the server.
Depending on your team size, you could:
publish right from VS
continuous integration, check out Cruise Control for info on that
combination of CI and file synch (i.e. CI to test server then xcopy to production)
I'd advocate for CI since you tend to find issues faster that way, but it assumes you are using good version tracking and testing practices. Copying files can have unintended consequences like missed files, outdated files begin retained, etc.
When you deploy that way, anyone who gains access to the web server (which may be beyond your control if it is hosted) can view and possibly even alter your .aspx pages.
One alternative, which you can use from within Visual Studio, is to compile everything into a binary. You do that by choosing menu Build > Publish > uncheck the checkbox "Allow this precompiled site to be updatable." The downside of this, of course, is that even the tiniest change in a page's HTML will require recompiling the code and redeploying it.
It's a clear tradeoff between security and manageability, but precompilation can also aid in performance. Here is one explanation of precompilation alternatives.
You might also consider the suggestions made in Key Configuration Settings When Deploying a Web Application. In a nutshell,
If you are deploying your web application to a machine that you have control over, such as a web server within your company's intranet or a dedicated web server at a web host provider, you can use the element in machine.config to force all applications on the web server to adhere to the recommendations provided above (namely, using a custom error page, disabling output tracing, and not having the auto-compiled code compiled in debug mode). Simply add the following markup to the machine.config file within the <system.web> element:
<deployment retail="true" />
Again, this is a pretty simple change to make.
On a project I work on, we originally built on a dev machine, zipped and copied the contents of the 'bin' directory across. (unzipping, creating a site in IIS etc...)
Later, when we had the time, we went for this approach:
Creating windows installers in VS2008.
This has worked really well, as (literally) anyone is capable of doing the deployment. The real beauty of this, is that you can account for This is just a fancy way of wrapping the process of copying the 'bin' directory across...
Food for thought I hope.
Dave
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...