I'm struggling to find anything at all on the internet about how to resolve this...
We have an ASP.NET MVC3 based website which uses Cassette to do resource bundling. I'm currently deploying the website onto a server for live use but we're hitting problems.
I have a staging/integration server where everything is hosted which is working just fine.
Using the same code and the same configuration, cassette bundling takes several minutes to complete when the AppPool "warms up" on the new server for live. I can tell it's cassette taking the time because I ran a Debug Diag analysis during the pause a few times and it consistently shows cassette is in the middle of a CoffeeScript bundling process. I had read on the Cassette website that CoffeeScript compilation can take a long time if the files are too big, but ours are quite small (we have about 6).
So my main question is: Is there anything that can severely hamper the performance of Cassette's initial bundling? Is it anything to do with the Isolated Storage Cassette uses to cache the bundles?
For reference the servers run IIS 7.5 on Windows Server 2008 R2.
Bonus round:
When things do eventually load I see the error "Invalid operation when bundle has no assets". Confusingly there's no referenced bundle path that is empty. Once again everything works on our staging server but not on the "live" server.
Many thanks for any ideas at all.
UPDATE
Setting the cassette configuration so debug=true seems to make everything work, including the "Bonus Round" problem. I'd quite like to use the benefits of not using debug mode like minification though so the question still stands.
Removing the session module in the web.config worked for me. Although not a solution for everyone, the application I'm working on doesn't rely on it.
Related
I have a site where I am getting:
I had to do a full re-install where this previously all worked fine, and this is going to Azure. I re-imported my publish settings from Azure and see this. That looks good too so I assumed we were back to normal.
Except that the "Publish Succeeded" stuff, when I visit that actual URL I publish to (which I had to blur), none of my changes are there.
Any ideas?
I'm fully checked-in on the git branch and this runs fine locally.
From your comments I understand you're using FTP to make changes to your Azure project. That's not really the best way of deploying an application in 2020, but for this particular issue that you're facing it doesn't matter what method you use.
The most likely scenario is that when you visit the URL you are being given a cached version of your website.
That can happen for multiple reasons:
1) Your browser stored a cached version of the website
2) You are using a CDN (content delivery network) such as Cloudflare, which most often comes with an enabled cache feature that ensures your users will get your static pages lightning fast
3) Your web application implements one or more caching procedures
If none of those is the case (ie: you have tried using incognito mode, you don't use a CDN and you haven't implemented a caching strategy) then you might need to double-check you have pushed to the correct branch and that the commits contain your recent changes.
EDIT: if you actually have everything checked, including that your Git repo is properly synchronized, then it might be worth trying a different deployment method -- normally it shouldn't affect the end result, but there is the possibility that the Microsoft Azure platform has certain hidden bugs - this being one of them.
Have you thoroughly check the directories and stuff if its correct? most of the time issues like this are some minor errors like cache, wrong directories, and same output from previous files etc.
We've recently launched a new website in Azure (i.e. Azure Websites) and as is typical with new launches we've had to deploy a few tweaks to fix minor issues shortly after launch.
We want to use Slots in the long run but this is not possible at the moment. Hence we are deploying to the live site. It's a fairly busy site with a good amount of traffic and obviously want to keep downtime to am minimum.
We are using Visual Studio to publish file changes to Azure but have noticed that even if we publish a relatively insignificant single file the whole site goes down and struggles to come back up. I was assuming that publishing a single file would literally just replace that file on the file system but it's behaving more like it recycles the application pool (or Azure equivalent) for the site. The type of files I've been publishing have been Razor views, hence would not typically cause a recycle.
Does anyone know what actually happens under the hood of VS Publish and if there is a way to avoid this happening?
Thanks.
I just tried this using a basically clean new MVC app (https://github.com/KuduApps/Dev14_Net46_Mvc5), and I did not see this behavior. The Index.html view has a hit count based on a static, which would tell us if the app or the page got restarted (or if that specific page got recompiled).
Then the test is to publish it, make a change to some other view (about.cshtml), and publish again. WHen doing this and hitting Index.cshtml, the count keeps going up, and there is minimal slowdown.
If you see it getting restarted after a view change, I suggest using Kudu Console to look at the files in site\wwwroot before/after the publish, and check what has a newer timestamp (e.g. check web.config, bin folder, ...).
Our production Liferay instance absolutely refuses to deploy my latest theme. Something is preventing it from displaying my latest CSS changes. Unfortunately, there are NO log errors and no Firebug Console errors, so it's been a real headache to diagnose. I just get a really ugly plain page with links and no styles applied.
I have tried everything I can think of to fix this.
Undeploy/redeploy theme
restart the Glassfish container
use Liferay Server Administration page to "Clear content cached across this JVM", "Clear database cache", "Verify Database plugins", etc.
undeploy, restart, redeploy
undeploy, delete leftover files/folders pertaining to the theme in 'applications' folder, restart container, redeploy
clear my browser cache
try a different browser
many more combinations of the above. You get the idea.
Last night I reached the boiling point because my theme deployed and displayed in our test environments without issue, but didn't work in production. The only thing that was different is that I wasn't using
include-and-override=portal-developer.properties
in my portal-ext.properties file.
I took a gamble and added this line to my production portal-ext.properties and restarted the production server. My theme now displays without a problem.
The file portal-developer.properties only appears to contain the following properties:
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=false
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.etag.ETagFilter=false
com.liferay.portal.servlet.filters.header.HeaderFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
So, finally, my question is, am I merely trading a slight performance boost for a massively easier deployment experience?
Or are there more serious concerns to loading this file in a production environment?
Thanks in advance for the input!
Ben
You'll get a really bad performance with that portal-ext.properties. That configuration is only intended to be used in development environments.
If you delete the css/.sass_cache directory on your deployed theme you'll see your css changes and you'll be able to use a different portal-ext.properties on production environment.
http://issues.liferay.com/browse/LPS-26939
Regards
Every time I want to add new code to my site I have to modify the file outside of users view to debug it before updating the real file users see.
I usually create a copy of the file I want to change and test all changes on it but sometimes this files only appear included on another and I have to create two copies and sometimes it becomes even more complicated.
How is this normally done? Are there any tools to simplify the process, for example and enviroment to test my site on my PC so I don't have to upload files to the server each time I update something. Any info about beta testing new features will be thanked.
Most people have a 2nd server (potentially a virtual machine) configured exactly the same as their live (production) website. Where this 2nd server is located is completely up to you, but it should match your live site by using the same versions of software and same file structure.
I also like the idea of a staging server suggested by Sean. Again, your post doesn't say too much about your production web server and all of the features that you're using (are you running scripts on the server? PHP? some version of SQL?). But for a simple setup, you can run a copy of the Apache web server on your own PC, or something a little more lightweight like the XAMPP server.
I created an ASP.NET MVC 2 application in Visual Studio 2008. I set the release build to go through the ASP.NET compiler to precompile all the views, minify Javascript and CSS, clean up the web.config, etc. Since the production deployment is going to an IIS6 server, I set up my pseudo-production deployment on my Windows 7 machine to have the application pool run in classic mode targeting the 2.0 runtime. I set up the extensionless handler in the web.config that's necessary and everything worked great.
The problem came when I upgraded the solution to Visual Studio 2010. I'm still targeting the 3.5 framework, but now I'm using MSBuild 4.0 since that's what Visual Studio 2010 uses. Everything still compiles correctly because it runs fine under Cassini, but when I deploy it to the same location (same application pool, identity, etc) it now behaves differently. I still have the extensionless handler in the web.config, but now when I navigate to the root of the application it does directory browsing, and any routes that it had previously handled now come back as 404 errors being handled by the StaticFile handler in IIS. I'm at a loss for what changed and is causing the break.
I have looked at this question, but I have already verified that all the prerequisite components are installed.
Did you try debugging your routes using Phil Haack route debugger on the server?
Edit:
On IIS 7.5 you dont need any special extensionless handler, this is handled automatically, you don't need to change anything. It is only necessary on IIS 6 as far as I know.
Could that be the problem? what if you remove that special handler? maybe this is what is stopping it to kick in the route engine.
Edit:
I double checked, and as I thought, starting on IIS7, the default mode of a AppDomain is Integrated Mode. This means that the Asp.net stack kicks in at every request, while in classic mode, asp.net was called only when an specific extensions where called (aspx ashx axd are mapped by default to the aspnet_isapi filter).
UrlRoutingModule is kicking in at every request without requiring anything from you because it is an HttpModule and not a Handler. (it just needs to be registered in the config file of your application, no need to map it to an extension, but that's by default in an MVC app. You can open you Web.Config file and verify that you have under a node
<modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>
Are you sure you deploy the MVC assemblies to the server?
Check that System.Web.Mvc, System.Web.Routing and System.Web.Abstraction references have the Copy Local property set to true to be sure you use the same assemblies locally and on your production server...
If all that is correct, I don't know how to help you more... I hope this will help you, or at least put you on the right tracks.
EDIT:
Oww... just read your last comment... sorry I missed that element about classic mode. Your title mentions IIS7.5 and I assumed too much things. that's why I got confused.
Honnestly now, I had to look in the book of Steven Sanderson. He has a checklist for troubleshooting IIS6 deployment.
I know you're saying it's only when using MSBuild 4 that it fails, but it might still be usefull
Check that Default.aspx is set as default content page. That could be the source of 404.
Then to have extensionless urls, last time I deployed to IIS6 I used a simple wildcard map and I never had a problem...
If you're still in trouble sorry that I could'nt help... not that I didnt try :) good luck
I experienced this problem today, in a similar scenario.
The problem on my case was due the fact that asp 32 bits was registered instead of the 64 bits, causing the problem with the routing.
It was solved by typing the following in the command prompt
CD c:\windows\microsoft.net\framework64\v4.0.30319
aspnet_regiis -i
Couple ideas to try
Have you run any kind of comparison
between the output of the VS2008 and
VS2010 projects? Just verifying that the
solution upgrade didn't change
anything.
Do you have the web.config
targetFramework attribute set on the
compilation element?
Are you certain you're not running
into something like running a x86 application
in a x64 app pool?
I'm guessing you're fine on those, but since Cassini has no problems with the application, I still lean toward web.config issues. Do you have your modules/handlers properly registered in the element? Since you're running Classic Mode, you'll need both the "old" and the "new" (reference 1, reference 2).
I've already posted this solution in another thread, but I'll repeat myself.
Use classic pipeline mode of AppPool:
Also dot't forget to install HTTP Redirection module in Turn Windows features on or off.