Short answer is No, we don't hard code anything in the control, you can see for yourself in the source.
What I suspect is happening is that you ran the control at least once using the demo data and it has cached the default configuration XML in your roaming config, by not specifying a new remote config file it will continue to use the cached one until
it's updated, this is to ensure that if your remote config file fails for any reason it will continue to use the last downloaded one, the "Project" configuration file is only used if no network existed.
Not using a "SettingsURL" at all should prevent it from using the cached one.
Now one thing I did notice while I was working on the update is that because we used the roaming settings initially, if you ever used the test remote config at any point using the same project reference from any machine using your Microsoft account,
then Microsoft will cache the settings for you and replace them when you next connect, so deleting the project folder locally does not clear the config file. In the next update I've changed this to use the Local Temp rather than roaming temp
and let devs change this behaviour if they wish.
To get around this for now either start a new project if your app is just starting and don't use the settings URL in the demo code, or put your own config file remotely somewhere and point the config to it to clear it from your machine / account. Granted
neither of these solutions are ideal but you've hit one of the "safety" features which would keep AdRotator running if it was unable to get config which in a real world situation is a great help but in test, not so much.
Hope this helps.
Should have the next version available soon after we've concluded testing, if you have any suggestions for the update now would be a great time to suggest it.