I changed config file of the windows many times. Before changing config file I stopped the service and after changing config file, started again. Every thing worked fine.
But last time when I made some changes in config file of the windows service and started it - It didnt worked, I even tried reinstalling the service but in vain.
As a last resort I rebuild the service with new config file and copied newly build files on the server and installed the service. To my surprise the Windows service worked perfectly this time.But I have only made changes to config file and the code of the windows service was untouched. My question is, do we need to rebuild the Window service if we change the config file many time?
If you're referring to the automatically generated .config file, then no, the service need not be rebuilt. My guess is that in your last iteration you forgot an end tag or something, which caused the service to fail to load it's configuration.
Related
I've got a custom http module in IIS 8 that uses a set of config files to control how it works. These are all named *.config and are mainly in a filesystem folder outside the scope of the site, with one in the bin folder.
In the module I use system.io.file.writealltext to update the files. When I do this, the file I'm writing to is copied to a .bak file before the new file is written to. This only seems to happen when the file extension is .config (I've tested with other extensions and it doesn't happen).
It also doesn't happen everywhere - it happens with all the deployments I have on an Azure Windows Server 2016 VM, but doesn't happen much on other deployments (we have clients with a variety of versions of Win Server & IIS).
I suspect its an IIS setting, to automatically create a .bak when a .config file is changed, but can't find any info on this.
Does anyone have any idea why this is happening and how I can turn it off?
I just deployed a new version of a WCF service to IIS6 via a powershell script which keeps previous versions (builds) of the service in the file system but points the application to the newest build virtual directory.
But upon testing the service I noticed that the behavior of the service was consistent with the previous version of the service not the latest (as latest build has a fix for an issue in the previous build, which I was testing).
So I checked the application's virtual directory path in IIS and it shows the correct (latest) build virtual directory. So I decompile the DLLs in the bin and indeed they are the latest.
I even attempted to remote debug the service and no break point was being hit despite the PIDs of the service and the attached process matching.
I then tried to switch the virtual directory back to the old one in order to switch it back to the new one (in the case of some glitch or bug in IIS or something) but when I set it to the old virtual directory the change would not persist, even after an iisreset.
At this point I am not sure what is causing this issue, any help would be appreciated, thanks.
I opened an existing project in VS2015, made some small changes and published the MVC application to my webserver with an existing WebDeploy publishing profile. This broke the application because the web.config file on the server was overwritten with the original one for my developers machine. I have checked the settings in the Publish-wizard but the configuration was like always before. I could fix the application by manually changing the web.config on production but am afraid now to publish again.
Has anything changed in the WebDeploy publishing method with web.config transformation?
I solved it. In my case the publishing profile was renamed to "servername (production)" and the configuration setting for the transformation was only web.servername.config. After changing the name of the publishing profile to the exact same name as the config setting it worked.
I've built and compiled my WCF client to run successfully. I've found that as long as these two files are together, my client will run anywhere on my computer:
Client.exe
Client.exe.config
When I move these files to another computer, there's an error:
System.InvalidOperationException: Could not find default endpoint element that
references contract 'Service.IService' in the ServiceModel client configuration
section. This might be because no configuration file was found for your
application, or because no endpoint element matching this contract could be
found in the client element.
I've already made sure that the service URL is accessible from the intended host of the computer.
After looking up the issue, seems like a solution is to copy the config retrieved from executing:
svcutil http://host/Service.svc
to the application configuration file. However, the config info is already in the App.config file when I built the project.
Do I need to recompile/build on every client machine that intends to use the WCF web service?
I seem to have resolved this by copying over the entire compiled folder:
Client.exe
Client.config.exe
Client.pdb
Client.vshost.exe
Client.vshost.exe.config
I don't have the time to go back and forth to see which subset of files are core or whether all these files are necessary, but hopefully someone can follow up with an answer to that.
Im trying to work in my project, when I change files it changes the file inside the directory that I imported the projects into my workspace. But the changes aren't showing up on the server because the server is using the folder inside .metadata/webapps/myapp etc
what have I done wrong here?
Sounds like you're deploying to the integrated Tomcat server. The deployment is normally to the .metadata/.me_tcat/webapps/myapp folder. Is this what you meant? If not then I suggest you remove the deployment and then deploy again and let the deployment location default. The folder .metadata/.me_tcap is simply where the integrated Tomcat installation looks for applications when it starts up.
You can check the deployment location by looking in the servers view. Expand the integrated Tomcat server. The deployment location for your project is shown there.
The deployed location should be kept in synch with your code. If that's not happening, it may be that the changes you're making are the kind that require a redeployment. I'm not sure what the conditions are for propagating changes but I guess there might be some situations where changes can't be picked up automatically in this way. The changes should be picked up on a redeploy.
To check, create a new web project, which will create some default configuration and a default index.jsp file. Deploy this to the integrated Tomcat server. Now make a change in the index.jsp file and save it. Check if the change is made in the deployment location, or simply run the server and check that your new index.jsp gets displayed.
For more help, I suggest you post to the forums at www.myeclipseide.com/forums