I have a project that uses ado.net dataservices. This project was originally developed in VS2005 and IIS6 but I am now porting it to IIS7 standards. I've run into a snag when trying to update existing records, the put operation (to the service) fails and prompts the following browser alert:
The URI 'http://localhost:6188/services/Datatracker.svc/provider' is not valid for PUT operation. The URI must point to a single resource for PUT opeations.
I imagine this is because the URI is being treated as a folder, and I know that this can be corrected through configuration but I'm having trouble finding the specific settings
Any assistance would be appreciated.
So as it turns out this is invalid syntax for put and delete requests:
http://localhost:6188/services/Datatracker.svc/provider
Valid odata syntax is: (OLKM represents the calue of the keyfield that uniquely identifies the record)
http://localhost:6188/services/Datatracker.svc/provider('OLKM')
Old asp.net + iis6 allowed you to cheat your way around this requirement, but iis7 & .net 3.5+ requires you to use the correct syntax.
Related
We have an existing CMS implementation, episerver 7.1, that has a .NET 4.0 app pool and is built against .NET 4.0.
This CMS is forms based and request authentication has been disabled for it. We have a custom page type that has an URL property, and we sometimes use a custom URI scheme in this URL property to dynamically look up catalog links in the code behind, mpc://16403 where 16403 us a unique ID for the product that is not market specific. [This allows the client to add the links once, and then the system looks up the correct market specific link]
We encountered an issue with a service on the machine and had to install .NET 4.5.
Suddenly we noticed that the custom links were being corrupted, changing mpc://16403 to mpc://0.0.64.19/
For some reason, after the installation of .NET 4.5, our custom URL is being converted to an IP address. None of the configuration has changed, only the installation of .NET 4.5.
Does anyone know why this is happening and how we can stop it from happening?
I would bet that under the covers, System.Uri is being used. If you look through the class reference, you will see that the class parses the string that is passed in to break it into its component parts (scheme, host, etc). In this case, it looks like the parsing logic was modified to assume that a hostname that consists of numbers is an IP address. As far as how to best handle this problem, it looks like you may want to either use strings (probably a bad idea) or a custom protocol handler.
OK, there seems to be a bug in how .NET 4.5 handles the System.Uri class.
Specifically it always applies IPAddress.Parse to the host, even if the scheme is unknown. This is wrong as not all 'hosts' are IP addresses.
The following code snippet produces mpc 00.00.64.19 in .NET 4.5 but in .NET 4.0 and .NET 4.5.1 it produces the correct mpc 16403
System.Uri myUri = new System.Uri("mpc://16403");
Console.WriteLine(myUri.Scheme + " " + myUri.Host);
So, if you want to use custom schemes with any class/feature derived from System.Uri do not use .NET 4.5 and go straight to .NET 4.5.1
I need to build a Web Service in ASP .NET 3.5 (C#) that accepts a large file (documents like DOC/PDF/XLS and similar of about 10-20 MB) as input parameter.
This Web Service is called by many 3rd party applications, many of which are developed in PHP. Once the WS has the file, it has to put it inside another .NET application documents archive.
I already tested the entire round and it works. The file wasn't passed inside the call url, it was taken by a server local path.
Now, my problem is: how can I pass a big file to the WS, when the calls come from an application that is hosted on a different server?
EDIT: added an example.
The case:
Server A is a PHP application that calls the .NET Web Service on Server B and passes it a file. Then, the WS on Server B will post the file somewhere else on Server C.
In other words my problem is the communication between Server A and Server B. I need something like a "query string" which I can use to pass a file as byte array or anything else. Something like:
http://www.myserver.com/InsertFile.ashx?file=A3Fdf3Gjy5... <-- byte array of the file
Obviously, the query string doesn't suit very well to my purpose...
I want to know if what I want to do is possible and which technic I should use to make it works.
You could use a POST instead of a GET to allow larger files (and be semantically correct). A similar question is asked here. Leading to this link
If the web service is yours you can achieve it by changing web.config file. Please refer :
How do I upload large (> 25MB) files to a web service?
I'm working on my first Windows .Net application (as opposed to a .net web app, which I've done a lot of), and I have a question about database connection strings - is there an equivalent to the section in web.config?
I want to be able to have the program run against our test database (which will required a different connection string. What is the "canonical" way to define connection string objects in a Windows .Net application?
Thanks
Rather than write this all down again, here's a good article on this subject:
Storing and Retrieving Connection Strings
Add an "application configuration" file to your project. It will add a file called "app.config" Put your connection in there.
When the app is compiled it will change the name of the config file to match your executable. For example: MyApp.config.
I'm not sure what you mean by "canonical" way to define connection string objects. Name them whatever you want. Sometimes we use the name of the database, sometimes just the name of the project.
With regards to having multiple config files, we use Config Transforms. Which name them app.config, app.debug.config, app.release.config, etc. and use configuration manager to define which one to use based on where it's being deployed.
Non ASP.Net apps simply use app.config instead of web.config. See here.
Connection strings can be stored as key/value pairs in the
connectionStrings section of the configuration element of an
application configuration file.
The challenge is to determine whether ASP.NET is enabled within IIS7 in a reliable and correct way.
Enabling/Disabling is done in this case by going into:
Server Manager ->
Roles ->
Web Server (IIS) ->
Remove Role Services ->
Remove ASP.NET
The natural place to determine this should be within the applicationHost.config file. However, with ASP.NET enabled or disabled, we still have the "ManagedEngine" module available, and we still have the isapi filter record in the tag.
The best I can find at the moment is to check if the <isapiCgiRestriction> tag includes the aspnet_isapi.dll, or that the ASPNET trace provider is available.
However these aren't detecting the presence of the ASP.NET config directly, just a side effect that could conceivably be reconfigured by the user.
I'd rather do this by examining the IIS configuration/setup rather than the OS itself, if possible, although enumerating the Roles & Services on the server might be acceptable if we can guarantee that this technique will always work whenever IIS7 is used.
Update
Thanks for the responses. Clarifying exactly what I want to do, I'm pulling settings from a variety of places in the server's configuration into a single (readonly) view to show what the user needs to have configured to allow the software to work.
One of the settings I need to bring in is this one:
The one highlighted in red.
I don't need to manipulate the setting, just reproduce it. I want to see whether the user checked the ASP.NET box when they added the IIS role to the server, as in this example they clearly didn't.
I'd like to do this by looking at something reliable in IIS rather than enumerating the role services because I don't want to add any platform specific dependencies on the check that I don't need. I don't know if it will ever be possible to install IIS7 on a server that doesn't have the Roles/Services infrastructure, but in preference, I'd rather not worry about it. I also have a load of libraries for scrubbing around IIS already.
However, I'm also having trouble finding out how to enumerate the Roles/Services at all, so if there's a solution that involves doing that, it would certainly be useful, and much better than checking the side effect of having the ASPNET trace provider lying around.
Unfortunately, if you don't check the ASP.NET button, you can still get the ManagedEngine module in the IIS applicationHost.config file, so it's not a reliable check. You can also have ASP.NET mapped as an isapi filter, so checking them isn't enough. These things are especially problematic in the case where ASP.NET was installed but has been removed.
It looks like the best solution would be to examine the Role Services. However, API information on this is looking pretty rare, hence the cry for help.
The absolute way to know if they checked that or not is to search the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components
In there you should see two values set to 1, ASPNET and NetFxEnvironment and NetFxExtensibility. This registry key is the IIS Setup key that contains all the components that have been enabled in IIS.
Determining if asp.net is even an installed feature (prerequisite for enabling it) can be done through PowerShell, which implies there is .net api out there for it if you dig hard enough. The PowerShell methods:
Import-Module servermanager
Get-WindowsFeature web-asp-net
Which will return an object of type Microsoft.Windows.ServerManager.Commands.Feature. The installed property is boolean and indicates whether or not the feature is installed.
So do you want the easy way? Make a nice pretty .aspx page that displays as HTML with an error block in a div in a placeholder saying "You need to install ASP.NET" and have it change on ASP.NET being installed to instead say "ASP.NET is installed" and then just have the tool launch this webpage in the default browser after copying it to the directory identified in IIS as the *:80 site (or create the directory mapping in IIS programmatically by altering the XML and then removing it later)
May not be the most elegant but it does ensure that testing shows what features are truly installed versus what's in an XML file.
Because that will scream "do it the lazy ignorant way" I'll remind you that the only way for me to know in javascript what features I can use is to test them before I try to use them, or assume they're there and watch it blow up. My point is, it doesn't matter what gets reported in a file, it matters what you can actually use. Just because C:\Windows\Micrsoft.Net\Framework\v3.xxxxxxxx exists and has files doesn't mean the dll's are registered in the GAC, does it?
I'm developing a webapp using tiles and spring mvc. With the use of xsd and dtd validation on the definition of tiles and bean declaration of spring mvc, each time the web app is start/restart, then requests are sent to external server for xsd and dtd files. I notice that because my webapp failed to start casually due to failed request to external server (!!!).
I wonder if there is a way to tell my app to stop doing that? Like place a cached version of these files somewhere, or tell the Xml Processor to not valid these xml files at run time?
I'm facing a similar problem (but with xsd files.) After a little research, it appears that generally, foo-1.0.jar will contain foo-schema-1.0.xsd and therefore when foo goes to validate its foo-config.xml, it doesn't need to ask the Internet for the xsd.
The problem comes when you upgrade to foo-1.1.jar (which includes the new foo-schema-1.1.xsd) without changing your foo-config.xml to reference the new version of the schema. foo-1.1.jar doesn't contain foo-schema-1.0.xsd, so the parser looks for it on the Internet. If the site is trying to look at is down, you have problems.
So check your xml files to make sure they're referencing the version of the xsd/dtd appropriate for the jar version which is validating them.