I have used server.mappath() in my application.It is working fine in debug mode,but after publishing into IIS it is not working.
string filePath=Path.Combine(HttpContext.Server.MapPath("/calendar"),
"MonthCalendarTest.exe");
Process.Start(filePath, Convert.ToString(LoggedInUserKey));
Tried with absolute path,
"../../calendar/MonthCalendarTest.exe"
"~/calendar/MonthCalendarTest.exe".
Please let me know where i am going wrong.
I guess this could be wild card issue, because after publishing website to IIS, it allow only those extensions to run which are mapped in the IIS. Please check the same.
Related
I request a page in Sitecore and I get a 404 from IIS. The site works on my development environment & staging. This is on the production machine, which is a new install. I've never actually seen it work. The fact that it's giving me an IIS 404 (instead of a Sitecore 404) seems to indicate that whatever handler Sitecore uses isn't being recognized or isn't set up properly. I'd appreciate any suggestions about where to begin looking or what the issue might be.
We're in II7 running in classic mode.
I have the same issues if I run Sitecore in classic mode. Why don't you try running in Integrated mode, for all handlers to work propperly? Your Sitecore login page works, so that indicates that you have unzipped the Sitecore folder corretly. I'd suggest you to try Integrated mode.
It sounds like a permissions issue, check that Network Service (or Application Pool Identity) has the correct access to all of the Sitecore folders.
This looks like a fairly good guide on this:
Sitecore folder & IIS permissions
You could also try exporting the IIS setup for production and staging and comparing the two to make sure nothing odd with the setup.
Have you tried running the installer? If you are cleaning up someone else's install, there's no telling what they did... far easier to start again. You can easily connect to an existing database, or install a package with all your content once you've got a good working Sitecore instance.
The RDCL report created via Visual Studio 2008 is working fine on the local server. But when the same application is hosted on the IIS, HTTP 404-File Not Found error is displayed.
Does anybody have an idea about this? Please help me.
404 is definitely NOT a permission issue. The virtual / relative / absolute path NEEDS to be verified, looked at and changed.
Try Fiddler or an HTTP Analyzer to see what the exact URL is and be sure it matches up.
Please make sure that the RDCL report file exists on the published directory and/or IIS.
I have a WebForms application hosted in IIS 7. When I run the site from Visual Studio 2010, my static content all loads perfectly. We have the same site hosted in another production environment and the site works great there also.
However, when I am trying to host the site in a new production environment, it is giving me a status code of 302 Found whenever it attempts to load the static content.
When I open up Chrome's Developer Console and look at the network, it shows this:
/login.aspx?ReturnUrl=%2fjs%2fjquery.js
This leads me to believe that something in IIS7 is forcing authentication to occur on static content. Is there anything I should check to see what the likely cause of this problem is?
Ok, for whatever reason, I had to add the IUSR user and give it access to Read on my web apps. I am not sure what changed that made this a requirement. If anyone knows, please feel free to add comments.
If you set the same permissions as for wwwroot folder the problem disappears:
Users and IIS_IUSRS - read access
I have a folder(/MyFolder/) with a dedicated web.config in it that does an impersonating
In that folder I have an asp.net file that use Microsoft report viewer 8.0 named MyReport.aspx
When I view this folder on my machine, it's working perfectly without issue
When I publish my project to the dev server and I'm trying to view the report, I have an issue where the the user that run IIS doesn't have access to something, (rsAccessDenied)
Can asp.net routing cause this issue?
(I'm not at work right now so I can only go by memory so it will be hard to provide more information)
Your impersonation is probably not set up correctly. Check the User.Identity.Name when running locally and on the server.
http://msdn.microsoft.com/en-us/library/system.web.httpcontext.user.aspx
In the end, asp.net routing was causing this issue, the web.config wasn't getting loaded.
I had something like this:
http://ip/myreport.aspx
I had to change it to
http://ip/reports/myreport.aspx
I had to have the folder in which the web.config was located in the url
I have an ASP.net Website. the project' content is in a folder called MyWebSite.
When I run my application from Visual Web developer 2008, the browser displays the following address in the address bar:
http: // localhost/ MyWebSite /Default.aspx
I want to be able to run my Website from the following address:
http://localhost/
Can anyone help me please?
Thanks in advance.
Since it is already running on IIS, I would just change the Physical Path of the Default Website. The original value for this field is something like below in IIS7.
%SystemDrive%\inetpub\wwwroot
If you change this field to the path of your MyWebSite folder than you will be able to access the web site from just http://localhost.
I have seen it recommended to change this value from its default as a means of better security. However, I am trying to think of any drawbacks to doing this and the only one I can think of is that hard coding the path might cause some of your other development relative paths to be confusing.
You can go in and change the bindings settings in IIS but I advise against this. If you deploy your site as is, it should resolve correctly on a hosted server (the way you want it). Try this first and see :-)
Create a new website on IIS named MyWebSite, then in Visual Studio do a File->Open->Website. Choose Local IIS and select your website.
Then it will just run it under what ever name you gave the website. In this case you could make it http://MyWebSite/
Note: running Vista and Windows 7 will need elevated privileges.