Ever since upgrading to Visual Studio 2010, I'm running into an issue where the first web request of any type (WebRequest, WebClient, etc.) hangs for about 20 seconds before completing. Subsequent calls work quickly. I've narrowed down the problem to a proxy issue.
If I manually disable proxy settings, I don't experience this delay:
Dim wrq As WebRequest = WebRequest.Create(Url)
wrq.Proxy = Nothing
What's strange is that there are no proxy settings enabled on this machine in Internet Options. What I'm wondering is if there is a way to disable proxy settings for my entire project in one shot without explicitly disabling as above for every web object.
The main reason I want to be able to do this is that I'm trying to use an API (http://code.google.com/p/google-api-for-dotnet/) which uses web requests, but does not provide any way to manually disable proxy settings.
I have found some information suggesting that I need to add some proxy information to the app.config file, but I get errors building my program if I make an edits to that file.
Can anyone point me in the right direction?
Brent - that's the correct solution : adding a defaultProxy element to your application's configuration file.
So for a website, it's the web.config. For an .exe application, it's .config.
And those settings are also correct :-
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy enabled="false" useDefaultCredentials="false">
<proxy/>
<bypasslist/>
<module/>
</defaultProxy>
</system.net>
</configuration>
Instead of turning off the proxy setting altogether you can try using the bypasslist to turn it off for the servers that you're having problems with.
See http://msdn.microsoft.com/en-us/library/kd3cf2ex.aspx for details and a sample.
If you're having problems changing the app.config I suggest posting the errors and possibly the app.config as well.
Related
I'm using the DefaultFactory LogManager for Nservicebus v5. I'm happy with this but was hoping to be able to disable via the web.config.
I use web.config settings, as found in the help docs
<configSections>
<section name="Logging" type="NServiceBus.Config.Logging, NServiceBus.Core" />
</configSections>
<Logging Threshold="Debug" />
I'd prefer not to set the threshold as fatal. I was hoping for a "None" or Disabled="true"
Also can the directory path be set web.config?
Update: Why would we want to ignore errors?
The short is we don't really have write permission on the servers.
The long is this isn't 100% true.
Our systems is moving towards microservices, the problem with this is that decentralized logging is a tracing/visualization nightmare.
So we moved flow tracing, exceptions, and limited tracing to a centralized system.
Programming Entry points (aka message Handlers, web api endpoints, etc) are nearly always wrapped in a try catch log throw on each handler, this covers all our programming errors. This isn't anything really that different to normal.
The centralized logging location sets of all the nice red flashing real time alarms one could wish for.
Which leaves only configuration type error left like missing queues, bad assembly bindings, faulty config files, or more runtime style stuff like IoC wiring (outside of the handler code).
With the centralized logging and monitoring of the error quests, it is fairly easy to detect when the service is broken and if it is then we turn on logging, restart, try the faulty issue, and fix.
Guaranteed delivery will take care of everything else once it is up again :D Gone are the days of 150mb log files spread across 10 different servers.
The simplicity of DefaultFactory was nice, as was not needing another nuget package and associated configuration.
Is this the correct way forward. Many would argue no.
Could we have done it better? yes we could implement the common logger interface and pass it into NServiceBus but we arn't quiet there just yet and the win isn't critical atm.
A side note: One really really nice thing about the way we log is that in our backoffice tool we have been able to simply show the flow for each "order", similar to using a correlation id in greylog.
Since this was not considered a likely scenario it does not have a first class API. But you can achieve this via passing in a null logger from any of the common logging libraries (NLog, Log4net, CommonLogging). I assume you are using one of these in your website.
So take NLog for example.
Install-Package NServiceBus.NLog
The in your webconfig
<appSettings>
<add key="disableLogging" value="true"/>
</appSettings>
Then in your global startup
if (ConfigurationManager.AppSettings.Get("disableLogging") == "true")
{
LoggingConfiguration config = new LoggingConfiguration();
LogManager.Configuration = config;
NServiceBus.Logging.LogManager.Use<NLogFactory>();
}
This is leveraging the approach documented here http://docs.particular.net/nservicebus/logging-in-nservicebus#nlog
I'm trying to implement Lucene search in Sitecore. Using the default Sitecore.Search implementation, I should be able to get a reference to the index defined in my config file and call index.Rebuild.
I tried using the RebuildDatabaseCrawlers script from the AdvancedDatabaseCrawler, but everytime I call Rebuild, it fails.
The error I receive is:
Lock obtain timed out: SimpleFSLock#C:\sites\MySite\Data\indexes\__mysite\write.lock
I've tried changing permissions (including giving Everyone full perms), restarting databases and IIS, all to no avail. I've also tried stripping my search configuration section down to the bare minimum, with the same result.
Unfortunately I don't have any visibility into what the index.Rebuild() method does, as its inside the Sitecore.Search assembly.
The issue ended up being related to configuration.
Specifically, when trying to remove all superfluous Sitecore.Data.Indexing references from the configuration files after determining that i didn't need both Sitecore.Search and Sitecore.Data.Indexing, I had commented out the following line:
<configuration>
<appSettings>
<add key="Lucene.Net.FSDirectory.class" value="Sitecore.Data.Indexing.FSDirectory, Sitecore.Kernel"/>
</appSettings>
</configuration>
That needs to be there.
Try to adjust the permissions for c:\Temp for your app pool user, e.g. Network Service
You can also try to do the same for: c:\windows\microsoft.net\framework\{version}\Temporary ASP.NET Files
Can anyone shed any light on this? I feel like I have wasted the entire day today hunting and searching the internet for any scrap of information about how to do this. I have created a very simple WCF RESTful service. It is basically a proof of concept. I have a simple database behind it and I am just trying to get it working so that I can view, create, update and delete items. Right now I only have view and update working. I'll tackle create later. For now I can't figure out why the delete doesn't work. Almost everything I have found so far tells me that I need to disable the WebDAV module. I did that and then I got PUT to work. But I can not get DELETE to work. Whenever I attempt to call DELETE through my service I get the following error:
The remote server returned an unexpected response: (405) Method Not Allowed.
So it seems like somewhere on my server it is not allowing the DELETE verb. But for the life of me I can not figure it out. I already checked the Handler Mappings and the handler allows all verbs for the .SVC extension. I have disabled WebDAV. I'm not really sure where else to look. I am using IIS 7.5 on Windows Server 2008 R2.
(I can provide code if it would help at all)
Thanks,
Corey
In case anyone having the same issue.
Here is another way you can try.
in web.config
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
I just spent a ton of time trying to figure out why I kept getting 405 Method Not Allowed when using the DELETE verb. Everything I read said to uninstall WebDAV from IIS, but that seemed to break IIS in that all sites gave 503 errors. I reinstalled it, then went about looking in IIS for some setting.
It turns out that WebDAV is the problem, and it has a node on the IIS features page named "WebDAV Authoring". Clicking on that lets you then click on WebDAV Settings... to get the properties page. In the section Request Filtering Behavior, set Allow Verb Filtering to False seemed to do the trick for me (YMMV).
This seemed to be a popular result when googling for a solution, so I thought I'd add to the list of suggested solutions.
Open your website's Handler Mappings in IIS Manager
Edit each handler you want to DELETE with, clicking Request Restrictions, choosing the Verbs tab, then add DELETE to the "One of the following" list or, if appropriate within your concerns, allow all verbs.
You might need to restart your website and/or recompile your code
Well I'm not sure if this is really an answer to my question but it did solve the problem. I simply started a new project in Visual Studio and this time I used the .NET REST Service template that I found online. Then I transferred the old code I had from my previous attempt and used it in the new project. It worked like a charm. All four verbs work correctly now (GET, PUT, POST and DELETE). So it is working now.
Corey
I have deployed a few WCF services to a server via a web setup project
they are being hosted in an IIS Application, which appears to be running fine.
However when i try to navigate to the wsdl, nothing is found.
I am trying to set up diagnostics logging, to get some information.
I have followed the advice from here: wcf trying to set up tracing to debug, not writing to log file
Also, I have tried what is in the referenced MSDN documentation: under "Recommended Settings for Deployment or Debugging" .. my web.config has that identical configuration. But no log file is being created.
Nothing useful in the event viewer.
Any ideas?
Could be a permissions issue; IIRC those don't always turn up in the event log. Ensure the user IIS runs under has write permissions to the log file path.
This is typically the diagnostic config I use. Seems to work for me.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Verbose">
<listeners>
<add name="sdt"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="D:\wcfLog.svcLog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
If you are not getting any output it may be because your service is not starting correctly. The ServiceHost must be up for diagnostics to output anything. With IIS even though your site is running it does not mean that the ServiceHost started correctly. It's usually a config issue. I'm not a web guy but doesn't IIS write to EventViewer if there is an unhandled exception in the website?
Also, you could try creating a custom ServiceHostFactory. That way your code controls the ServiceHost creation and you can trap any exceptions and log them on your own.
Creating a custom ServiceHost in IIS -> LINK
This is an old question but for the benefit of anyone who might stumble upon the issue:
Make sure you have configured both the system.diagnostics and the System.serviceModel/diagnostics sections configured.
Make sure you have them configured in the correct App.config/Web.config file. The thing to note is that multiple config files may exist in a project, and the one used depends on the Build Configuration.
Personally I had the very same symptom until I noticed that I put the sections
under app.config (in my case, client side tracing), instead of
app.DebugLocal.config. The later was used as my build configuration was set to DebugLocal.
my web service was working, then suddenly it stopped. After debugging I realized that there might be a problem in the config, and for some reason the .svc mapping was gone in IIS (Handler Mappings).
I added the .svc mapping, and it is now updating my web.config and adding a node to the web.config (my previous web.config's didn't have this node and it was working just fine).
Ok, so I then upload my original web.config, now going back to IIS it shows that the .svc mapping is deleted again.
Has anyone else experienced this strange behavior?
Work-around RC1 problem - Manually map .svc to aspnet_isapi.dll
see:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/054b1d90-1e75-42ff-8d18-639f0b273dad/
I assume you are using IIS7 since your web.config keeps getting changed. Can you post the code that gets added to your web.config?
Also, are you setting this mapping at the application level in IIS? If so, you (or someone else) might be changing mappings at a higher level (or lower if you are working higher) which caused the initial problem.
If you don't need any special or custom behavior consider using the Factory attribute of #ServiceHost, you then won't need any config...
http://msdn.microsoft.com/en-us/library/aa967286.aspx