I am creating web application in C# using ASP.NET MVC and I am using MSSQL server installed on my machine.
Also I wanted to publish application as open source project, and run it on production server.
Should I add web.config file to source code repository? If i should, how I should track "open source version" (pointing on MsSQL installed on localhost) and production version (pointing on my hosting of web.config (I am using Mercurial).
The recommended way to do this is as follows:
Create a copy of the public version of the file you'd like people to use as a starting point, and name it something other than the actual usable file. In your case, it could be web.config.template. Make sure the file would be usable if you just renamed it.
Instruct Mercurial to ignore the actual file, ie. web.config
If possible, make the build process figure out if the actual file is present, and if not, make a copy from the template file into the actual file
If step 3 is not possible, a batch file to make the actual file is the next best thing, or simple instructions on how to make it.
This ensures that:
There is a simple way of getting the actual configuration file
You can edit your local actual configuration file without worrying about committing it (it is ignored)
If step 3 was possible, this is largely transparent unless you need to make modifications to the file
Step 3 can be handled with a pre-build event for your project, something like:
if not exist web.config copy web.config.template web.config
You could commit a generic version to your repository, probably on the initial load only (so that the project will build for those who don't know how to create their own), and then add an ignore rule later so that you can add your connection strings and whatnot.
Related
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
So this was quite a hilarious error and was quite difficult to trace, so I'm going to chuck everything on here in case it happens to anyone else;
While working on a website in production, its name changed. I noticed that the IISExpress instance displayed not only the new name, but a '\' and the old name as three separate instances.
As I was attempting to add log4net to the project, I attempted to use this line in the web.config:
<log4net configSource="log4net.config" />
Which caused the following error on app run:
the configSource file '[file]' is also used in a parent, this is not allowed.
the configSource file is also used in a parent, this is not allowed.
This was perplexing as I had not used this source anywhere else, and no matter what file I changed it to, I got the same error.
log4Net worked fine when I defined it entirely within my web.config, but that's not what I wanted, so I investigated further. Interestingly, a colleague who'd just been brought onto the project could run the app fine with the separated config, but I and another dev who'd been working on this project for a while could not.
How can I and another colleague with exactly the same setup have a failing app with the same config as someone with a fresh checkout have it work fine?
The web.config file is "composed" when it is read by the application by scanning the file system from the current directory up to the drive root and by looking in a number of pre-defined places (such as the location of the Machine.Config and the default ASP.NET config.) If you're using Virtual Directories on the same website in IIS, things can turn even more interesting.
Any of these files can define configuration sections and can possibly externalize the configuration, and thus cause the error message you're seeing.
The following doc on MSDN outlines exactly how the configuration is being parsed and composed:
https://msdn.microsoft.com/en-us/library/ms178685.aspx
It turned out to be that IISExpress had saved the previous settings in a .vs folder at solution's root level, and all three of those instances were using the same config, and looking for the same file, hence the error.
The solution was as follows:
In the web-app's project, reset the web properties to look at the root site (\ instead of \newname\)
Trash the entire .vs directory
Restart Visual Studio and Reload the project.
For different versions of VS, the .vs folder is in different locations on your machine.
I have installed the spring security core plugin. I need to modify the login page to look like my existing website. I have searched the entire project and cannot find it. I am running grails 2.4 and spring-security-core:2.0-RC5. Where can this pesky little file be? Can someone who is not a complete greenhorn help a fellow out?
As #Abs points out, the file is at target/work/plugins/spring-security-core-2.0-RC5/grails-app/views/login/auth.gsp but you shouldn't edit plugin files. Other developers on your team won't have access to the modified files and if you delete the target directory you'll lose your changes since the target directory is only a temporary work location.
Instead, copy the file to the same relative location in your application and make changes there. Create grails-app/views/login and copy the file there and make whatever changes you want.
This technique works for most plugin files, not just GSPs. The compilation order and classpath are configured such that application files and classes override plugin files if they're in the same location/package.
You can find the default login page here
targt->work->plugins->spring-security-core-2.0-RC5->grails-app->views->login>auth.gsp
As sf_sandbox has set up the symfony environment, why not develop in the sandbox directly and then upload on to server? What are the disadvantages of sandbox compared with configuring manually?
I think there is no drawback in following this approach. sf_sandbox is a pre-configured symfony project. One of the pluses is that is saves you time in creating your project and initializing an empty application (by default this is called frontend).
It's more a matter of taste rather than a matter of right or wrong. It's up to you!
Note: If you follow this approach you have to make some initial configuration (steps 1,2,3 would be done anyway if you started your project from scratch):
Rename the project
Change the config/properties.ini file
Change the config/databases.yml file (by default sf_sandbox uses sqlite database)
Remove the data/sandbox.db database file
Does anybody know how to (easily) "rename" an existing grails application? I'm running into this because my PaaS provider does not allow me to delete a subscription... So I want to deploy my application under a different name.
Of course, I can do this manually, but I think it might be a useful 'top-level' script (i.e. "grails rename-app newappname")
Manual hints:
When I do a "grails create-app myappname" I can see the myappname exists in the following files (and filenames)... Of course this is done by the create-app script, which replaces #...# tokens in the template. I guess once they are replaced, it's not trivial to do a rename.
./.project: <name>myappname</name>
./application.properties:app.name=myappname
./build.xml:<project xmlns:ivy="antlib:org.apache.ivy.ant" name="myappname" default="test">
./ivy.xml: <info organisation="org.example" module="myappname"/>
./myappname-test.launch:<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="myappname"/>
./myappname.launch:<listEntry value="/myappname"/>
./myappname.launch:<listEntry value="<?xml version="1.0" encoding="UTF-8"?> <runtimeClasspathEntry containerPath="org.eclipse.jdt.launching.JRE_CONTAINER" javaProject="myappname" path="1" type="4"/> "/>
./myappname.launch:<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="myappname"/>
./myappname.launch:<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dbase.dir="${project_loc:myappname}" -Dserver.port=8080 -Dgrails.env=development"/>
./myappname.tmproj: <string>myappname.launch</string>
And of course... the top-level directory name is "myappname"
Any hints, or information about ongoing initiatives in this area are welcome
Greetz,
Johan
I had to do this, I renamed my project top level directory to the new name and
edited the application.properties file. There is a line app.name=youroldappname which should be changed.
Actually, you do not even have to rename the directory. You could have a different web-app name.
Hmm, I know it doesn't look fun, but it shouldn't be difficult (just boring) to rename the project directory, then all the files with your project name in them (you can ignore .tmproj unless you use TextMate). Finally, a quick search through all the files for your old project name to replace and you should have it.
Oh! First, if you're using an IDE, you'll want to remove the project from the IDE, then re-import it once you've completed your renaming procedure.
As far as I know, nothing project-specific is stored anywhere except the project directory and below, so it's a very finite set to search, and you only have to do this once (I hope).
Not very elegant, I know, but brute force does have its uses.
I used the brute force Method and it worked for me. Took 5-10 minutes to find all files with the name in it and replace it with the new one. Also Netbeans was ok afterwards. The only thing that changed was the port number which I had to change again.
Just renaming works except when you are using plugins. They will be stored in the $USER_HOME/.grails/$GRAILS_VERSION/projects/OLDNAME folder.
So after renaming your project you "lost" your plugins. I haven't tried renaming the plugin's folder however just installing all your plugin works as well (at least with Google App Engine and gorm-jpa).
If only changing the web app name isn't enough you can try the rough way - make a backup before.
(In workspace folder)
zip -r oldname.zip oldname/
Then, in eclipse/ggts, use
Disable project, Build automatically
Search, File, Containing text : "oldname", Search
Right click on search results, Replace all, ... "newname"
Exit eclipse and rename all folders to the new project name. On Unix/Mac run
find . -name "oldname"
and mv the handful of results to properly reflect the new names.
For me it worked like a charm, but make sure your project name is not a keyword and reasonably unique.