I have embedded tomcat container running and deploying project demo and its dependency jars in the following path:
c:\users{user}\AppData\Local\Temp\Stem_Tomcat\webapps\demo\Web-Inf\lib
Issue is, windows cleaner will delete the web-inf\lib files periodically. This happens even when the supporting Stem application is still running although the demo webpage may been closed.
How do I configure to prevent web-inf\lib*.jars from being deleted when Stem is still running ?
I was hoping to do this without having to resort to change the java.io.tmpdir location path to something else.
For context, we were originally using Jetty and windows was not able to delete the files when the Stem application was still running. I am unsure what conf changes needs to be done.
Related
I'm currently working on a live project. The frontend part of the system is in ReactJS. We are using create-react-app as the starter kit.
We are facing some issues in deploying the application on live server. Earlier we followed the strategy of pushing the code on server and then creating the build on it. But we noticed that so long the build was generating, our site became unavailable. Which does not seem right. Hence we decide to create build folder in developer's local machine and push the build to the server. But now we are receiving a lot of change requests and feature requests, hence I'm planning to move to a robust git branching model. I believe this will create problem with the way we are currently handling our deployment strategy(which is to move the build to production).
It will be really helpful if some one can show us the right direction in handling deployment of ReactJS apps.
You can use Jenkins which can be configured to trigger the build as soon as a code in a branch is checked-in in GIT. I have not worked on Jenkins but surely, I have seen people using Jenkins for such things.
Jenkins will trigger the build in its own environment (or you can create a temp folder for the time being the build is getting generated if Jenkins operates on the server directly) which will generate the output bundle. So your code will not be removed from the server for that while and you can patch your new files to the actual folder (which can also be automated using Jenkins).
I'd need to have wpf app in a shared folder from where users could make a shortcut and run it having an opportunity to right click on the shortcut and run it also as a different user.
So, I'm wondering if I could copy all files from the bin/release folder if it could work. I did publish the app and installed it on another computer but it seems as there is no possibility to use a right click with the run as a different user. So, I did also copy bin/release files there and made a shortcut from the bin application file and the run as a different user seems as working from that shortcut on that machine. But, it might be not a right approach. The publishing and installing might not be an option further as well as it would need to go through TFS eventually where it would be copying files from a one environment to another.
I did implement it through TFS. The TFS is finally generating mainly the same files as in bin/Release when it's built via VS.
I have two application configuration files in my application directory. One is named Test.config and the other is named MyApp.exe.config.
Test.config is similar to MyApp.exe.config with slight modifications.
If I execute MyApp.exe, it uses Test.config to run as certain aspects of the application is configured within these configuration files. However, if I rename MyApp.exe.config to MyApp1.exe.config, the application will not start.
If I delete Test.config, application launches correctly using settings in MyApp.exe.config. This is a .NET 3.5 WPF application.
Anyone run into this.
TIA.
I'm attempting to deploy a WPF application to IIS. After copying the files to the server, when I attempt to download and run the .application file, I get an error:
Application cannot be started, please contact the vendor.
The detailed log shows the error:
Deployment and application do not have matching security zones.
I noticed someone else had a similar problem a while ago.
Can anyone help?
This error was due to me copying the wrong root path up to the web server. I copied the entire "Release" folder to my target URL, but I needed to copy just the app.publish sub-folder.
I encountered a couple more problems on the way:
My deployment included some files in the App_Data folder. IIS7 was blocking this, and I needed to remove "App_Data" from the "Hidden Segments" of "Request Filtering".
I started seeing an error "my.dll already exists in some-random-temp-folder". I just excluded the DLL from my deployment files. I think it had already been marked as "prerequisite".
There's an excellent answer here that provides instructions and some context.
We have an net 4.0 winforms application that we publish with clickonce to the client pc's. The installation is about 80 MB. The application is offline available and the update occurs in the startup of the app using
ApplicationDeployment.CurrentDeployment.Update
Each time we do an update of the application everything works fine and each client gets udpated. However the application cache keeps growing in size... We noticed that more then two versions are kept in the LocalAppData folder. The size of the clickonce installation folder is more then 1GB.
ClearOnlineAppCache works only for online applications and we don't find any information to clean the LocalAppData for offline application.
Is there any way to manage previous versions of our application in the LocalAppData folder from our client pc's?
Update:
We removed our custom update code and used the update mechanism of the Clickonce framework. Now old versions are removed properly and only two versions are kept in LocalAppData. I have still no idea why all versions are kept when we update through the custom update code.
I've seen this issue before, but I clarified with the ClickOnce lead at Microsoft before answering.
It keeps two versions of the deployment plus there are extra folders for each assembly. When processing an update, ClickOnce figures out which files have changed by comparing against the assembly it has already cached, and it only downloads the ones that have changed. The deployment folders have hard links to the assemblies in the separate folders. So you might see additional files, but it's not actually the file, it's a link to the files in the assembly-only folders. Explorer will show it as a file, but it's not. So unless you're running out of disk space and are just concerned about the folder size, be aware that the information reported by Windows Explorer may not be accurate.
There is an answer to this problem here
I wrote a function to clean old ClickOnce versions in the client side.
In my machine I've freed 6Gb of space. I don't want to even know the total space used by old versions org wide...