I have a separate project which performs watiN tests. The project is in the form of class library project. When I run test it launches the browser and then uses the Web.config of the Web Application Project which I am testing. The Web.config of web application project has the Dev connection string which should not be used for testing.
What are different ways that I can take and tell my WatiN to use the App.config that is inside the WatiN project and not the Web application project?
Here are couple of options that I have:
1) Replace the connection string at runtime.
2) Replace the connection string at pre-build event or something.
Here is what I did:
Before a test is run there is some custom code that goes to the Web.config file and then switches the connection string from DEV to TEST.
After the test is completed it changes it back to DEV again!
Try using this way of copying your whole config file (you can tweak it to do it before & after to swap the test & QA connections strings)
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
Related
I have a .net windows application, and i to run this application on client machine through asp.net web page.
I have used the Click-once technique which is publish the windows application in a setup package and place it as an IIS Application.
Now i want to pass a parameters to the windows application.
to pass parameters the click once app i am using a URL to .application and pass parameters as query string parameters file, but the problem here is the .application file doesn't setup the prerequisites first, i.e if the client machine doesn't have .NET framework installed the application will return error !!.
can anyone tell me how to pass a parameters to click-once application and check for prerequisites first.
also if there's another technique rather than click-once please tell me.
In the properties window of your windows application project, look for publish tab. You can set the prerequisites in this tab.
Here is also the detailed instructions from MSDN.
In some of the solutions we have ASP.NET/WCF web project and a test project. Some of the tests run against ASP.NET development web server using http://localhost:port/.... In VS2010 while the ASP.NET/WCF web project was being debugged, the test runner could run the tests and if there were any breakpoints in web project, the debugger would break the execution. This seems to have been disabled/removed in VS2012.
When the ASP.NET/WCF web project is debugged (launched by pressing F5 or via attach process), both the TEST->Run and TEST->Debug sub-menus are disabled. In VS2010 only Test->Debug sub-menus were disabled while Test->Run sub-menus were still enabled. We use this way to easily debug the services within the web project. Any way to get that behavior back or workaround?
Debugging While Running on ASP.NET Development Server doesn't seem to be applicable to VS2012 or at least I can't get it to work.
In VS2013 the situation is the same: the options for running / debugging tests are greyed out while the project is being run/debugged. This is a shame especially for projects like web API's where tests for calling the API via HTTP (as opposed to creating an instance of the Controller class and circumventing any network traffic) are very useful as they are closer to what the end users of the API will experience.
As a workaround, you can either open the same solution in a separate instance of VS, or create a separate solution with the same projects, specifically for testing. Debug in the first VS instance, run tests in the second one.
If you have a solution with WCF applications and tests calling them, you can debug the applications using the tests by calling Debug All Tests or Debug Selected Tests without a previous Start Debugging (F5).
Configure your solution to Multiple Startup Projects with None set in all actions and configure your WCF applications to the start action Don’t open a page. Wait for request. With this configuration the development web server starts if you select Debug All Tests or Debug Selected Tests.
Here is a workaround to debug a single unit test along with a web server. It relies on Debugging Multiple Processes (excludes MSVS Express):
Start web server (non-debug), note its process id (IIsExpress icon -> Show All Applications)
Place a breakpoint at first line in test
Start Debuging the Unit Test, wait for it to stop at the breakpoint.
Debug -> Attach To Process, enter web server process id
Both the test and server are running live in the debugger.
I ended up writing a quick addon. It turns out that like VS2012, VS2012 test runner can also run the tests when the web project is being debugged. It is just that menu options are disabled.
Try this:
Place a breakpoint in the first line of your unit test method.
Start debugging your unit test.
Once it hits the first line in your unit test, start a new instance of the other projects you need running.
This is not a pretty solution, but it works. Using Azure DevOps TFS Version Control, create a branch of your current project. Open the solution for your project, in the other branch, in another instance of Visual Studio at the same time as your main project is running in the first/original instance of Visual Studio. Then, run your web project in your first/main Visual Studio instance. Now, run your unit tests from the other instance of Visual Studio. Voila.
To keep them in sync, you can do Merges from one branch to the other.
I still ran into this on VS 2022.
If you have multiple projects you can run. Try to set the startup projects and set at least two of them. (solution->right click)
If two instances are running in debug mode, VS also allows you to start unit tests.
(I just started two aspnet api-s from my project)
My solution has two projects. A class library to generate data from an Entity Framework .edmx file via a repository class. The App.Config file connectionString matches the Web.config in my second ASP.Net 4.0 web forms project.
I modify BOTH connectionStrings to point to the test database (DataSource=TestDB) when deployed to the test server. When deployed to the live site I modify both to point to the live database (DataSource=LiveDB).
At the top of Site.Master I display in red letters "You are connected to the TEST database" in a label control. I conditionally toggle the .Visible property of the label if (context.Connection.DataSource.Contains("TestDB"))
During development I noticed something strange. When Web.config points to TestDB, if I forget to make App.config match (and it points to LiveDB) the "connected to TEST" warning appears but data from LiveDB displays.
This tells me the repository (class library) uses App.Config but a data context created in the web forms project uses the Web.config connectionString. Is that correct? I'm concerned that live data will be updated incorrectly if I deploy to the test site and forget to point App.Config to TestDB.
So my question is, in this scenario... What is the best way to display a notification "connected to test database" that is always accurate?
By default a class library will not be using any app.config file.
It would use the .config file that is in the context of the application using it - in the case of a web application that would be the web.config file.
When the app runs, it's using the one in web.config, no matter where the context is created.
Why not set up the firewall on your live application to prevent access from (a) anywhere except the live webserver, or (b) especially your test location?
I am developing one product and there are 4 separate projects, in that I have developed one EXE project and WCF and I have done switching in debugging mode by attaching WCF project in process of debugging client of EXE and it has worked.
But when I transfer my WCF to servicestack then I could not able switch between them.
I am running my EXE project and and attached my WCF(servicestack) project to process
JsonServiceClient client = new JsonServiceClient("MYServiceURL");
RESTWCF.ServiceModel.Perfmon objBalPerformanceDataProperties = MakeObjectForServiceStackToInsertData();
var res = client.Post<RESTWCF.ServiceModel.Perfmon>("/perfmon", objBalPerformanceDataProperties);
When I click F11 on client.post I could not able to switch in WCF project, I think you can make sense of my problem.
Give me some solution of this problem so I can debug my code of WCF project (to find error :) in that)
Thanks.
You can only debug one host project at a time.
If you want to test the server set the ServiceStack project to be Start-up Host and press F5 to start debugging the ServiceStack host. Put a break-point at the start of the service you want to hit.
You can then just Run (i.e. without debugging) the client application which if everything is configured correctly, it should hit your breakpoint.
To make sure you're debugging the service correctly, instead of running the client first try calling the web service via a url, e.g:
http://localhost/MyServiceUrl/perfmon
If it hits the break-point you set, then all is well and you can run the client application as mentioned above.
Also it's a good idea to include ServiceStack's debbuging symbols, i.e. it's *.pdb files in the same folder as it's *.dll's - as it helps with debugging.
Note: WCF has nothing to do with ServiceStack - In a lot of cases that's considered an insult :-)
I want to test ASP.NET application using NUnit, but it seems WebConfigurationManager.ConnectionStrings collection is empty when running from NUnit GUI.
Could you tell me how to initialize this collection (probably in [SetUp] function of [TestFixture])? Should I copy Web.config somethere?
Thank you!
NUnit .config file location depends on how you created the NUnit project file
Where .config files for NUnit tests are located is a little bit more complicated than other posts here suggest. There are settings for this in the NUnit GUI Project/Edit dialogue. The default values all depend upon how you created your NUnit project file.
When you open the NUnit GUI and select File/Open and then select a .dll file a new project gets set up with settings to look for a config file with the same name as the dll in the same directory. So if you loaded \bin\debug\MyTests.dll NUnit looks for \bin\Debug\MyTests.dll.config by default. The only trouble with this is that when you create a release build you need to create a separate NUnit project.
If you have created the NUnit project by selecting File/NewProject then the default setting is to look for a config file with the same name as the NUnit project. So if you created \MyNUnitProject.nunit NUnit looks for \MyNUnitProject.config by default.
The chances are you have used Visual Studio to create an \App.config file and stuck it in the source folder for your test dll. When you buld your test project this gets copied to \bin\Debug\MyTests.dll.config or \bin\Release\MyTests.dll.config depending upon the configuration you have selected. If you have opened the MyTest.dll directly in NUnit this will work fine, however if you have created a new NUnit project you’re in trouble as it will not look for these files by default.
To resolve the issue you need to open up the Project/Edit dialog in the NUnit GUI and check that you have two Configurations Debug & Release to match your .Net project. Once you have done this you can select the Debug Configuration and set the ApplicationBase to bin\Debug\ and set the Configuration File Name to MyTests.dll.config. Do the same for the Release configuration and away you go.
If you have your unit-test assembly named Company.Component.Tests.dll, then just make sure that Company.Component.Tests.dll.config is there with the proper connection string.
Additionally, it might be a good idea to decouple your connection provider class from the configuration, so that you will have flexibility in persistence (i.e.: switching from *.config to something else) and easier testing.
Also check out "How NUnit Finds Config Files"
You can use the app.config for libraries (where I assume your tests are) and put them in there.