Develop Reference

ExchangeService FindAppointments returns 'This property was requested, but it wasn't returned by the server' error

I'm using Microsoft.Exchange.WebServices.dll version 15.0.847.30 to interact with functions in Outlook. I am using this call:
EWSData = CurrentEmail.FindAppointments(WellKnownFolderName.Calendar, new CalendarView(t, t.AddDays(1)));
(where t is today +/- however many days the user has clicked from today) which passes the WellKnownFolderName and the CalendarView directly through to a call to ExchangeService.FindAppointments.
I have a couple clients who each have a single user who is getting the 'This property was requested, but it wasn't returned by the server' error on some days and not others. Sometimes it pulls in the first few appointments for a day and leaves off the rest. My email, creating appointments, and add/remove contacts functions are all working for them.
I've traced through the ews-managed-api code from github and found the error is thrown when a property is requested but is null. I'm assuming the code on github is much newer than the version I'm using, but if the error is still caused by that code is in my version, I do not know how to find out what properties are causing the issue.
Since I'm not requesting anything specific but using the generic call with the folder name and a date, I'm quite confused as to what properties would be null and why.
What can I do, without re-compiling my application, to track down the problem properties?

Just a thought: do you have a way of tracing the XML flow between your app and Exchange, e.g. Fiddler? On the error response, you may be able to plow into the XML and see the name of the property causing the issue. Not 100% sure on this, but about the only tactic you can try without rebuilding you app with more diagnostic code in there.

What is the difference between CurrentDomain and UserDomainName?

Recently, a customer complained that our product was not populating the domain name.
Our code uses the Username and the User's Domain Name to query their membership rolls in Active Directory.
In our code, we use Environment.UserDomainName:
var domain = Environment.UserDomainName;
When I looked at this simple line of code, I discovered it could raise the PlatformNotSupportedException and the InvalidOperationException.
Looking for an alternative method of reading the domain name, I came across AppDomain.CurrentDomain:
var domain = AppDomain.CurrentDomain.FriendlyName.Split(".".ToArray())[0];
That is nice, but it also appears to have an AppDomainUnloadedException that could be triggered.
First Question:
Will these 2 methods always return the same information for a given user who is running our program on a local PC?
Second Question:
Is one method less "exception prone" than the other (again, for a given user who is running our program on a local PC)?
Last Question:
Is there a method of getting the local domain name of the user running our application that will not cause an exception to be thrown?
EDIT: For Tyler Lee

Did you even try to see what the value of AppDomain.CurrentDomain.FriendlyName was?
To Answer question 1: No, they will not.
Question 2 does not seem to apply considering question 1
Question 3: probably not. Environment.UserDomainName seems to be the source for getting a network domain name, and as you found, it has the potential to generate exceptions. The MSDN page gives details on when those exceptions are thrown, and you should write your code to be able to deal with it if they happen.

The AppDomain.CurrentDomain Property is the domain of the current application and the current thread.
In other words, this is the domain of a project.
In Visual Studio, under a Project's Properties page, this would be referred to as the Project's Assembly Name.
By contrast, Environment.UserDomainName Property is the name of the network that the current user is logged in through.
The two are not related.

Web API returns results but doesn't hit breakpoint even when symbols are correctly loaded

This is the weirdest thing that has ever happened to me so please hear me out.
Symbols are getting loaded properly. So thats not an issue.
API is working and the data is valid.
I've 2 controllers in the same project. One controller's breakpoint is hit when I make a GET request. But the second controller's breakpoint isn't getting hit. However it does return results correctly.
I'm putting a breakpoint at the constructor level (and have tried everywhere else) but not sure what is going wrong.
The code is pretty normal C# MVC web api.
Does anyone know what might cause this behavior?

One trick I like to use is to use Exceptions. First you change some public method in your "bad" Controller to just unconditionally throw some dummy Exception. Then call that method from whatever uses you WebAPI and make sure the Exception is actually thrown. Sometimes something get cached and code is not actually re-compiled or something.
Then attach your debugger and see if it catches the Exception. You might be attaching to a wrong process.
Next modify code to throw and catch that Exception and just log it. The trick here is that VS Debugger has an option to stop even on caught aka "user-handled" exceptions: see configuration here for VS up to 2013 and here for VS 2015+. Then you can see if symbols actualy matches the code.

I had similar issue - try this site out that might help
breakpoint issue
Meanwhile try to force a breakpoint
System.Diagnostics.Debugger.Break();

Does the controller, which works but doesn't hit the breakpoint, output cache whatever it is that is being generated? If it is, the data will be returned by whatever is caching it, and the controller won't be instantiated.
It's not clear whether you are using MVC or WebAPI controllers or what you are returning. However if it's MVC you could look for the [OutputCache()] attribute. You could also keep an eye out for other cache related headers which might be getting added.
Depending on the caching strategy you might be able to circumvent it by adding a random query string value so that it has to create a new cache key. For example:
http://example.com/some/path/1234?cow=moo

try this instead
1.Go to project "Build settings"
2.Search Debug
3.Under Apple Clang - Code Generation check "Optimization Level"
4.Set Debug to None [-OO]

I had the same problem just a moment ago before writing this down... Try going to properties of you webapi and compare if the project url found in the web section is the same as the url specified in your website's webconfig file. As for my problem, the website was pointing to the webapi properly which allows any code changes in the webapi to be read however, the debugger is pointed in the wrong place thus it cannot read any breakpoints you place.

WebAPI 2 Routing/hosting mishaps

I am having a bit of a terrible time getting a WebAPI 2 setup to work. I am trying to place this within an already existing solution containing multiple projects.
The current layout is (with generalized names):
-Server.Project
-Services.Project
Right now, IIS is doing the hosting. There is an application setup in IIS called Application.
So, right now if you go to localhost/Application/service.asmx , everything spins up and does it's thing. The global.asax.cs file and most of the service classes are in Services.Project, even though Server.Project is the software's entry point.
I want to make use of WebAPI's new things.
I've defined a controller (TestAPIController) in Services.Project, and a configuration file with the default mappings (from all of the examples). The Register() function is called from Application_Start(). I've verified that it is at least being called.
If I go to:
localhost/Application/TestAPI/anything ever, it gives me a 404 error.
I tried to use the Route Debugger by installing the package and going to localhost/Application/rd (also tried /Application/TestAPI/rd). Neither work. I get a 404.
This leads me to believe I have something setup wrong so that the WebAPI stuff is not actually spinning up and hosting correctly.
I have tried doing the OWIN startup as well, but it didn't seem to help.
For that, I just added the appropriate startup class stuff to my web.config, and to my Global class in Services.Project.
I've verified that the Configuration() function for Owin is being called as well, but I still cannot hit the paths I've setup.
I think the fact that the entry point is Server.Project, but the controller/routes are defined in Services.Project might be part of the issue.
However, all of the assemblies are placed in the same bin directory. I was lead to believe this should allow everything to be loaded/found.
Am I missing something?
If anything is not clear, sorry. Let me know so I can clear it up.
Thanks.
EDIT:
So, I got a different route debugger to install and cooperate.
(install-package RouteDebugger).
If I hit my main URL: localhost/application
This route debugger launches and shows that no paths were matched, but it ALSO shows the routing paths that I defined but are not found.
...so now I am even more confused. How are they showing up and obviously known about, but are unable to be reached?

If you followed "typical" WebAPI setup tutorials, you would have defined the custom ApiController route to include "/api".
All of your urls should look like:
localhost/Application/api/TestAPI/anything
As an aside, it might be worth it to just spin up a brand new Web API project. Retrofitting an existing project might cause more headaches than it's worth.

External Config Files (configSource) Dropped From Memory (MVC, C#, ASP.net)

We are having an intermittent issue where config files, or more specifically subset of values within that data are getting lost into the ether. Truth be told I am at a loss as to how to approach it because I am unsure if it's a code, config, machine or IIS issue. To give you an idea of what's happening....
What we are doing
We have a config file that contains "price" drop down values :
<searchForm>
<priceLowerBoundValues>
<priceLowerBoundValue>2500</priceLowerBoundValue>
<priceLowerBoundValue>5000</priceLowerBoundValue>
....
</priceLowerBoundValues>
....
</searchForm>
These are contained within a file named searchForm.config. In web.config they are referenced as an external file like so.
<searchForm configSource="Config\searchForm.config" />
We have a custom configuration handler that inherits from IConfigurationSectionHandler. The gist of being this code here that gets the values.
var priceLowerBoundValueXPath = "/searchForm/priceLowerBoundValues/priceLowerBoundValue/text()";
searchFormLookups.PriceLowerBoundValues = section.SelectNodes(priceLowerBoundValueXPath).Cast<XmlNode>().Select(x => int.Parse(x.Value));
Then the ONLY place we reference it, is when building a select list for the viewmodel. It looks a little like this :
SearchFormConfiguration.PriceLowerBoundValues.ToSelectList((parameters.PriceLowerBound != null) ? parameters.PriceLowerBound.Value : 0)
There is no modifications done to the list ever, and using resharper "Find Usages" only brings up this single call. No other point in the program touches these values.
The Issue
What will happen intermittently is that the drop down boxes on our webpage suddenly have only one value (e.g. 2500 in the price box). Do note it is not completely empty, but usually most values are gone. We have had similar issues of external configs dropping (almost completely) and it causes null reference errors across the place. e.g. it's still looking for a config that's supposed to be there, but it has been wiped from the face of the earth.
Stopping the website, stopping the app pool, and then bringing everything up again fixes the issue. Which made me initially think it could be something with memory usage, and external configurations being the first thing it drops, but I'm really unsure at this point.
Another thing to note. We have an app pool restart in the early hours of the morning everyday.
Any help with this is much appreciated, even if it's just a nudge into the right direction. As I say, I can't find any info on where to start, be it IIS settings or code. :)

I have an idea of what might me wrong.
Line
x.PriceLowerBoundValues = section.SelectNodes(...).Cast<XmlNode>().Select(...);
Basically a lazy enumerator over the XmlNodeList.
From MSDN docs:
The XmlNodeList object returned by this method will be valid while the
underlying document remains unchanged. If the underlying document
changes, unexpected results may be returned (no exception will be
thrown).
Is there any chance that the underlying document changes?
Will there still be problem if you put values to, say, array? Like ..Select().ToArray();