I've written an NUnit test project against an ASP.Net project. The code being tested cannot find the configuration values (in Web.config) when invoked from my test project. What is the right way to provide these configuration settings so my tests will run?
Take a look on NUnit's documentation about Configuration Files - it's pretty good explained how to handle your case.
You can create an app.config file for your test project. Just put the configuration values you need in here.
Related
I've got dev, alpha, beta and production environments. I store a few appsettings keys in web.config and use transorfmations to replace dev-setting with production-setting on publish. How can I do same things to replace dev-setting with alpha/beta-setting when publish on corresponding server ?
Yes, it is. You will need to create new build configuration for each additional transformation you need. See post from Troy Hunt here where he is talking about config transforms among other things
I recently take over a web application project using websphere and log4j running under AIX. To create a development environment, I setup all the components in windows, using eclipse to compile a WAR file and deploy it.
All is working fine except that log file is not created.
I changed the log file in log4j.properties from something like in below and and give everyone full access permission to the directory:
log4j.appender.F1.File=/abc/def/logs/admin.log
to
log4j.appender.F1.File=c:/logs/admin.log
What else can I check?
I create a simple standalone testapp which use the same log4j.properties and it can create the log file, but when the servlet deployed to websphere, it doesn't work. Please help! Thanks!
Ok, I think this article should help you. It seems that WebSphere CE uses log4j by default and controls it with a global properties file. There is a section on how to use application-specific properties files.
Here is what I try and do to troubleshoot similar issues.
Turn on log4j debugging to see where it actually picks up the file from. You need evidence of which file is picked up (so turning the debug on is a worthwhile activity) This provides you information with what log4j is trying to do to locate the configuration file.
-Dlog4j.debug=true
I would not hardcode the log4j location in the code. Instead I
would use the log4j.configuration System property and state that in
the JVM arguments. This way even I don't need to touch my code.
-Dlog4j.configuration=file:///home/manglu/log4j.properties
I would use this approach irrespective of the runtime server that I use (be it Tomcat or WAS CE or WAS)
Hope this helps
I suggest you use environment variables set on your server like this :
You must access the admin console of your server.
Under custom properties
Server_path=/abc/def/logs
In your log4j, use this : {$server_path}/log.txt
Make sure the user running the app has access to that directory.
I'm struggling to get web.config transformations working with automated builds.
We have a reasonably large solution, containing one ASP.NET web application and eight class libraries. We have three developers working on the project and, up to now, each has "published" the solution to a local folder then used file copy to deploy to a test server. I'm trying to put an automated build/deploy solution in place using TFS 2010.
I created a build definition and added a call to msdeploy.exe in the build process template, to get the application deployed to the test server. So far, so good!
I then tried to implement web.config transforms and I just can't get them to work. If I build and publish locally on my PC, the "publish" folder has the correct, transformed web.config file.
Using team build, the transformation just does not happen, and I just have the base web.config file.
I tried adding a post-build step in the web application's project file, as others have suggested, similar to:
<target name="AfterBuild">
<TransformXml Source="Web.generic.config"
Transform="$(ProjectConfigTransformFileName)"
Destination="Web.Config" />
</target>
but this fails beacuse the source web.config file has an "applicationSettings" section. I get the error
Could not find schema information for the element 'applicationSettings'.
I've seen suggstions around adding arguments to the MSBuild task in the build definition like
/t:TransformWebConfig /p:Configuration=Debug
But this falls over when the class library projects are built, presumably because they don't have a web.config file.
Any ideas? Like others, I thought this would "just work", but apparently not. This is the last part I need to get working and it's driving me mad. I'm not an msbuild expert, so plain and simple please!
Thanks in advance.
Doug
I just went through this. Our build was a bit more complicated in that we have 8 class libraries and 9 web applications in one solution. But the flow is the same.
First off get rid of your after build target. You won't need that.
You need to use the MSDeployPublish service. This will require that it be installed and configured properly on the destination server. Check the following links for info on this part:
Note that the server in question MUST be configured properly with the correct user rights. The following sites helped me get that properly set up.
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html
How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?
The next part requires that your build definition have the correct MSBuild parameters set up to do the publish. Those parameters are entered in the Process > 3.Advanced > MS Build Arguments line of the build definition. Here's a hint:
(don't change the following for any reason)
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=False
/p:MSDeployPublishMethod=WMSVC
/p:SkipExtraFilesOnServer=True
/p:AllowUntrustedCertificate=True
(These control where it's going)
/p:MSDeployServiceUrl="https://testserver.domain:8172/msdeploy.axd"
/p:UserName=testserver\buildaccount
/p:Password=buildacctpassword
/p:DeployIisAppPath="MyApp - TESTING"
Obviously the user will have to be configured in IIS on the target server to be allowed access to that axd (see previous links). And the IisAppPath is the name of the website on the target server.
You won't have to do anything special for the config transformations as the build itself will take care of that for you. Just have the correct setting in the line at Process > 1. Required > Items to Build > Configurations To Build.
Instead of trying to do the deploy by adding tasks myself into the build process template, I followed advice in Vishal Joshi's blog post here.
Now the entire project is built and deployed and the web.config transformations work also. Brilliant!
I now have another problem to solve! The web application references web services and the build process results in an XmlSerializers dll. However, although this is built OK, it does not get deployed to the web host. I think this needs a new post!
Doug
I’m a fan of the new VS 2010 Web.config transformations. I use this feature for deployment purposes and wondered if it is possible to use them for debugging too.
I think of using them in the IDE: I want to create different built configuration (with linked transformation configurations); choose one of them; start the web site in the IDE and debug the different configurations this way.
Update
Thanks to a 3rd party plugin, SlowCheetah, this is now possible. Scot Hanselman has a blog post about it.
Original response:
Unfortunately, the web.config transformations appear to effect only publishing sites and building deployment packages.
In our scenario we have two development groups, one with access to multiple environments (in-house) and the other with access to a single environment (offshore). We have periods where the in-house group needs to debug directly against QA, while offshore remains locked-out (so their web.config's must point to the dev environment).
We were hoping to have 1x build-configuration per-environment, and be able to choose the build-configuration which matched the environment to debug against--which, as I understand it is your question.
In case anyone is curious why they haven't built this feature, from:
http://forums.asp.net/p/1532038/3711423.aspx
"When the web app gets run, the web.config under project root folder will be picked up by asp.net and I know unfortunately it is under source control . I certainly understand the cleanness coming with letting runtime use a transformed web.config from a temp folder; however, asp.net runtime doesn't know anything about vs projec structure and it is totaly based on directory structure. Using alternate path might also break as a web.config under a subfolder expect to inherit settings from the upper level of directory."
I found an alternative solution that does not involve any third party tool: http://ledtalks.blogspot.in/2011/09/webconfig-transformations-when.html. I only tried this for the web.config file
I am using the built in test framework in VS2008 and I would like be able to write a test that makes sure all the expected web.config settings have been defined so that if by accident one is removed or changed my suite of tests will detect it and not have to be tested in a runtime scenario. How would I set this up?
I do not want to setup a mockup of my web.config since I don't want to maintain two versions and this would make my test invalid anyways since I am really trying to capture the fact that the project's web.config is correct.
Any suggestions, alternatives, hints?
Solution: I ended up using the copy in the pre-build that was suggested with one change. On copy I rename the web.config to app.config so that the test project would automatically pick it up.
I tried to split out the config files as suggested as well but the problem I ran into was when the test project ran, it actually didn't run out of the bin directory (which setting the config files to 'Content' type would copy to) but instead to a results directory that has been pre defined. I could not figure out how to make it copy thos extra files to this results directory so the config files could never be found.
I'am using the pre-build event to copy working web.config to your test project directory.
Set the command line of the pre-build event of test project to string like this:
copy $(SolutionDir)\YourWebAppDir\web.config $(ProjectDir) /y
After that your tests will always run with actual web.config version.
Comment to pcampbell's answer:
I think if you use the configSource attribute you can just set it to the same path in web.config of your web app and app.config of test project and that makes not necessary to use build events.
sorry, I can't leave comments yet.
To expand on bniwredyc's answer, perhaps consider:
refactoring your web.config to reference a new config file like appSettings.config or similar.
modify your project's web.config to:
<appSettings configSource="appSettings.config" />
modify your Unit Test project's app.config to use this file as well.
modify your post or pre-build events to copy just this file.
this also helps ease of deployment in Test/Staging/Prod
Ultimately, the web.config is an XML file. You could generate a schema to validate the sections required are present and that required values have been populated. Obviously, you couldn't contextually validate any sort of business logic that the configuration might contain, but you could use a combination of an XSD validation plus a lightweight class that is used to parse conditions within the file.
Used in conjunction with a copy pre-build event you actually create a very nice test harness for your production quality configurations.