I have been trying to set up some tests for a web api 2 project that I am working on. I have tried both of the methods in the following article with some success.
http://blogs.msdn.com/b/webdev/archive/2013/11/26/unit-testing-owin-applications-using-testserver.aspx
I hit problems because there are configuration settings in the web.config file that seem to be completely ignored using either of these methods. For instance, the database connection strings and other application settings are ignored.
When I run OwinHost.exe from the root directory of my Web Api project everything works more or less as expected, honouring the settings in web.config.
How do I get the WebApp.Start or TestServer.Create methods to reference the web.config file in the Web API project?
Is there another way to do this that I am missing?
Related
I am having troubles hosting the blazor wasm asp.net core hosted application.. The solution has 3 projects: Client, Shared, and Server.
when I run the command dotnet publish --configuration Release it publishes the libraries to their respective folders in solution like this:
WebWorkbench3\Client\bin\Release\net5.0\publish
WebWorkbench3\Server\bin\Release\net5.0\publish
...
I would assume that since the server project is referencing a client - then my steps to host the application are following:
Open WebWorkbench3\Server\bin\Release\net5.0\publish in powershell
Run command dotnet .\WebWorkbench3.Server.dll
Navigate to: https://localhost:5001/
Result:
Expected: client page opened
Actual: page is stuck at "Loading.." string. In the console we see that there was an error about _framework/blazor.webassembly.js not being loaded.
If we were to check the wwwroot folder contents in the server app we will see the following:
So this explains why the error is shown. However my question at this point - should the publishing process/configuration in project take care of copying client's wwwroot contents into the the server's app output directory? If we start a debugging session in the VisualStudio, then we use the server as the startup point, so the project should have some idea where to look up the blazor.webassembly.js file at..
So why doesn't the same process occurs during the publishing?
Note: I was able to fix the issue by manually copying the client's wwwroot directory and by placing the contents into the server's wwwroot directory... But I don't think that is is how serving is supposed to work?
EDIT: I have just tried to set-up the client blazor application in IIS. And it works. Kind of. The page is opened. But then when it tries to make a REST GET request to the server - it uses the same hostname:port combination. So if my app is hosted on mysite.local:50001 then the request to API will look like mysite.local:50001/data/loadall where data is the controller name and loadall is the action name.. So basically the client uses the same base address as the server.. The problem, is that I cannot start the server on the same port as the client! In attempt in doing so - you will see following output:
So basically I have the same question as before - how to host the wasm application that is split between client and the server? I am pretty sure that I can make it work by forcing the client to use the non-standard server port and serving the server part on that port.. However, I believe there should be a reason why current configuration (default configuration in the blazor wasm template) is configured in this way so it should be possible to run the project somehow without any additional changes at all..
Well this will be a self-answer.. Instead of publishing (dotnet publish --configuration Release) the application on solution level - do the publishing on project level..
before ..\repos\WebWorkbench3\WebWorkbench3
after ..\repos\WebWorkbench3\WebWorkbench3\Server
In 1 case the compiler does not copy the _framework folder (and possibly some other files) into the wwwroot.. Once you have published the Server correctly you can access the app by serving it with dotnet .\WebWorkbench3.Server.dll command.
Having the samie issue as explained above:
Before:
The solution file
had the same name
was in the same folder
as the server project
Resolved
I moved the solution to the project root (one level up).
Now, dotnet publish within the server project produced the __framework folder + content as expected.
Im looking to add a web.config (or app.config) so that i can have different settings (e.g. DEV build vs RELEASE build, for instance).
Can i simply add a .config file and expect to read from it?
I noticed that there is also an option to add a appsettings.json (App Settings File).
Which one of these should i be using for Blazor Client app (hosted via Asp.net)?
Thanks
Updates
Based on the following thread, i might just go with a settings
file on the Server side and feeding it to the Client via API.
Here is another reference for appsettings.json vs web.config
I was able to find a more concrete example int this article.
I believe you can use appsettings.Development.json and appsettings.json
Hope this helps...
I have created a WCF Service Application project and created a single .svc file with a single method that takes a string and returns a string. I published the service to our IIS test server (not local machine IIS) and I can see the default page when browsing to http://wcftesting.com/WCFService.svc.
At this point, I am going to create a small html page to test that I can access this service and that it returns data properly. Before doing that I googled around to see if there were any pre-requisite steps that needed to be taken, but couldn't find anything concrete and most of the information was at least a few years old.
Is there anything else that needs to be done to make this work? Everything is pretty standard. No changes have been made to the web.config file, and no additional attributes have been added to the methods. I had seen some mentions of added RESTFUL attributes to the operation contract, but in all honestly I'm very new and wanted to keep things as bare bones as possible.
We are using Visual Studio 2015 and I believe IIS 7.
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.
I have a very simple ASP.NET MVC 4.0 website. It's got a single controller ("HomeController") with a single action ("Index") which receives a single parameter ("string id"). I have not modified the global.asax file since this kind of route is handled by default. I have not created a view for this action since the action will simply be "sending" the user a file (a PDF). If I run the site from within Visual Studio (using a default page of "home/index/3" in project properties), the page runs fine. If, however, I publish the site to our test server (https://ourserver.com/mysite/home/index/3), I get a 404--File or Directory not found.
NOTE: We're running IIS7.5 on this server.
UPDATE: The bin dir (and the appropriate DLL, i.e., one named after the project) and the web.config file are there.
So, why is this not working?
If you're using an older version of IIS and haven't installed the MVC server extensions which give you routing, you can do a BIN deployment of the necessary infrastructure files.
Edit: If you're running IIS 7.5 you should have everything you need. You mention you don't see a web.config file or any dlls - how did you publish? You should absolutely have a web.config at the root of the publish directory and a bin folder with your dll(s).
If you right-click on your web project and do Publish, you can publish to a local directory. It'll be exactly what you should see when deployed.
Edit 2: Did you check that it's configured in IIS as a web application and not just a site?