My web application has been working fine. Just recently, I began trying to add Twitter Bootstrap to my project using NuGet (it doesn't appear that NuGet is the issue because the same thing happens if I add TB manually). After doing so, I noticed that my app was misbehaving ... some items that I was displaying to a page from server-side cache were missing.
As I dug into this, I realized that my app was being re-loaded on almost every call. I placed a break point in BundleConfig and sure enough ... almost every call, I'm hitting the break point.
If I uninstall the package, things start working fine again.
Furthermore, it doesn't seem to be just Twitter Bootstrap. It seems that if I install any new packages into my system, this starts happening ... almost as if I'm pushing IIS Express over some sort of memory boundary?
I've tried to verify some of the normal IISExpress issues with re-compiling ... things being written into bin, etc. But I don't see any activity on that front (and I'm definitely not explicitly writing anything there). I'm not writing to web.config in code or anything either.
Last bit of information -- if I publish the non-working app to my QA server, everything works fine. QA server is full-blown IIS -- not express. This further confirms that nothing is being written into bin or messing with web.config.
EDIT
When I say I added Twitter Bootstrap, I mean that all I did was add it to the project. I haven't even referenced it in any pages. I haven't included it in my bundling/minification, etc. It's basically just sitting there unused but still causes my app to recycle/recompile.
Related
I amb developing a web application with the frontent using typescript and vue, and the backend using spring. All deployed into a machine with tomcat9.
For some reason, everytime I update the application my boss calls me days later stating that the application stoped working. I then go check, but works fine for me, ask me boss to clear cache site and then it works for him to.
I dunno why, but this always happends to my boss and not me.
At first I thought this was happening cause I wasn't updating the version on the package.json file. But this doesn't solved the problem.
Any hint on what I can do to avoid this behaviour? Any workarounds would also be appreciated. As a developer I don't mind clearing the cache but our clients....
I have a Blazor WASM application using .Net Core 6, and all of the latest nuget packages, hosted using Azure App Services.
As per my understanding, the browser caches the application DLLs appending a sha256 hash code to the filename. The browser keeps the DLLs cached until it reads a new sha256 hash value on the blazor.boot.json, at which point it replaces the old DLL in the cache with a new one.
As per my observations, this works most of the time. If I look at my own browser application cache, using the dev tools, I will see the same version the DLL today, tomorrow, and the next day, as long as there hasn't been any deployments. Then, after a deployment, I open the application in my browser, go back to my cache, and without needing to manually clear anything or do anything out of the ordinary, I will see the DLL with an updated sha256 code.
However, every once in a while, this isnt the case. For example, I have a user, that rarely uses the development environment. The version of the application dll has been cached since august (2 months ago). Additionally, the contents of the blazor.boot.json correctly indicate the new version of the dll. But still, the old version, with a different SHA hash, remains in her cache.
I've seen this behavior before. I can't quite put my finger on what the difference is in the application changes that lead to successful automatic cache busting vs when the old cache continues to persist.
The simple solution is to have the user delete the entire blazor-resources group of dll's to force a new download. However, as we expand the footprint of the app to new users, I don't want to have to ask them to clear their application cache as we are deploying new versions of the code.
Given this example, it seems the failure is somewhere between the retrieval of the updated blazor.boot.json and whatever standard javascript runs to retrieve the new DLLs, which I believe is in the service-worker.js.
Any assistance regarding:
An explanation of why this might be happening (so that I can reliably reproduce the issue and have a valid test case after it's been fixed)
What code/configuration I may be able to force the DLL download... not on every refresh of the app, but at least when the SHA hash has changed.
Thanks,
Mike
I've inherited a Silverlight/WCF application. (Having worked on .net MVC, and SPA for quite a while)
I tried switching the IIS website folder to see if a tweak to the code and a fresh build would work, it didn't work and I switched back and although the website is functional it has a number of faults.
For some reason the Windows authentication appears to have stopped working, this authorises a number of the admin functions. I think this is broken and so not enabling the functionality in the Silverlight app.
The server I've inherited has the applications as folders in the default website, which is new to me, and quite constraining. I've gone through IISAdmin videos, and learnt a lot, but not enough to fix the issue.
I am unable to get the software to run in VS2013, quite a bump after working on Single Page Applications.
I'm stumped as to how the same code put back no longer works; I've learnt my lesson, but I still need to fix the system. I am not sure whether IISReset would make a difference since the AppPool is recycled every 29 hours. I've found out what the harm in trying is, and so I am proceeding with caution.
So my main goal would be to get the Windows Authentication working again.
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
I have a very strange issue that i cannot figure out.
First i have a WCF service 4.0 done in VS2010.
the service have couple methods that return string array, datatable and such.
some of them use function from C++ dll throught [dllimport]
i made a test console to test everything. when i run the WCF from visual studio and use the generated path it works wonderfully.
now here is where it become strange. if i open my local IIS create a new application and point to my VS source code the WCF i can see it perfectly.
now using the http path from IIS local instead i refresh the methods all seems correct. But when i run my test app i can call any unction without any problem EXCEPT anyone using DLLIMPORT functions. they ALL crash and cannot trace even by tracing CES exceptions.
Doing line by line logging show that the exception is really on the call of those functions
the DLL in question is the same and the path is hardcoded for my computer since still in test phase and the folder is c:\DLL\mylib.DLL so nothing to do with shadow copy IIS/visual studio do when you actually run. also DLL reference by name withotu path even if it's in sys32 doesnt work.
Any clue ?
also. 32bit, changing app pool level right access on folder, full admin on machine already too. all tried but unsuccessful.
Edit: adding to all that since i haven't made this clear, it's not my first WCF real setup. i've already made alot of services before and deployed them myself (probably somewhere around 50-60 services). I am asking because i have never seen this issue before and i tried all tricks i knew and could find on the internet and resource people i know.
We have decided to incorporate the whole service in the WPF project locally since it work as long as IIS is not hosting. but this is really not a good thing as this data and work should NOT be done on client side but instead on server side. Right now it's fine since the software that need to use this is not released to public yet so it isn't critical.
Next option will be net TCP/IP windows service hosted on the web server if i don't find anything else.
We decided to go trough the trouble of having to hard code the logic in the main software and get away from web services for this issue. we will have to deal with updating, installing unregister and re register unmanaged DLL by hand somehow but at least it works.
we have added over 5 web services since that happen and no problem with them but again none of them use DLL imports.