Just wondering if anyone has successfully got ccnet 1.6.x running on an XP box (IIS 5.1). I have it installed and it builds projects (failing at the moment most likely due to file permissions), but for some reason the mapping in the web.config for showing the build XMLs via the dashboard does nothing. All I get are 404 errors. The same also goes for some projects loading of parameters, e.g. http://localhost/ccnet/server/local/project/someProject/ViewProjectParameters.aspx . Don't ask why the "server" is XP, but it is.
Well I figured out what the issue was. As it's IIS 5.1, I installed IIS Lockdown. I didn't realize that by default, URL paths with dots in them that aren't the file extension dot are disallowed by default. I set the [AllowDotsInPath] = 1 in the urlscan.ini and it works like a charm now.
Related
I work on an ASP.NET web project which was migrated from target framework 3.5 to 4.5. After migration to 4.5 there is an issue with the redirecting of HTTP requests. A redirect from a called web page which is located in a subfolder causes a duplication of the root folder and subfolder in the called URL (but: no duplication with same code in 3.5). The affected subfolder is not registered as separate web application.
Hosted files are:
/WebAppRoot/SubfolderInWebApp/Page1.aspx
/WebAppRoot/SubfolderInWebApp/Page1.aspx.cs
/WebAppRoot/SubfolderInWebApp/Page2.aspx
/WebAppRoot/SubfolderInWebApp/Page2.aspx.cs
Page1 should redirect to Page2 using tilde (~) to address the root-relative path. Redirect call within /WebAppRoot/SubfolderInWebApp/Page2.aspx.cs is:
Response.Redirect("~/SubfolderInWebApp/Page2.aspx", false);
On my local machine using Microsoft Visual Studio and IIS Express the redirect points to
/SubfolderInWebApp/SubfolderInWebApp/Page2.aspx
On the test environment running IIS which hosts the app in WebAppRoot the redirect points to
/WebAppRoot/SubfolderInWebApp/WebAppRoot/SubfolderInWebApp/Page2.aspx
If I change the redirect call to
Response.Redirect("/Page2.aspx", false)
it works. But this is not really satisfying, knowing that it worked with the tilde before migration and keeping in mind that there are several other places in the application which work with the tilde (but not used in a redirect).
Here some details about my used setup:
local machine for development: Microsoft Visual Studio Professional 2017 15.9.49 (running IIS Express on local machine)
test environment: IIS 8.5.9600.16384
both setups use the
application pool ".NET v4.5 Classic" with .NET CLR version v4.0.30319 in classic pipeline mode
I wasn't able to identify possible reasons for this behaviour yet. As far as I understand the behaviour before the migration is the expected one. But I am not very experienced with ASP.NET, so maybe I misinterpret some information or I did not use the correct keywords in my search to find a solution. Also I did not identify issues in this list of breaking changes which could be the reason for the current behaviour. But maybe I am not aware of the impact of some statements in this list.
Any idea what might be wrong in my project? Is there an obvious configuration I miss? Is my expectation of the behaviour wrong? Thanks in advance for your help.
I solved it with help of Leo's answer here. The relevant control was firing an asynchronous postback which caused the described behaviour above.
When migration to 4.5 the HTTP module ScriptModule was removed from the web.config. Integrating this module again did not work for me and I wasn't aware of this. After defining the relevant control as PostBackTrigger by using the Triggers element within the UpdatePanel, it worked again:
<asp:UpdatePanel>
...
<Triggers>
<asp:PostBackTrigger ControlID="ControlWithSyncPostback" />
</Triggers>
</asp:UpdatePanel>
After this change everything works as expected again and there is no need to keep the ScriptModule declaration in the web.config (at least in my case).
for the past several days I've been experiencing this error, while publishing to either JBoss EAP 6.3 or Wildfly 8.2 from Eclipse.
Error renaming D:\Servers\wildfly-8.2.0.Final\standalone\tmp\tmp9064011157118650757.jar
to D:\Servers\wildfly-8.2.0.Final\standalone\deployments\BusinessService.war\WEB-INF\lib\spring-web-4.2.3.RELEASE.jar.
This may be caused by incorrect file permissions, or your server's temporary deploy
directory may be on a different filesystem than the final destination. You may adjust
these settings in the server editor.
The problem occurs when I "Add and Remove..." projects from the server, then try to publish them, so the server can start.
I've experienced this issue on two different machines (home (Wildfly) and work (JBoss EAP)).
I'm using:
Windows 7 / 10
Eclipse Mars / Luna
JBoss Tools plugin 4.3 / 4.2
JDK 1.8.0.66 / 1.8.0.65
Maven
Building with maven from Eclipse and from the command line makes no difference. The server is configured to deploy projects as compressed archives. On both machines my user has administrator rights and has full rights on the server directory.
So far I've tried:
recreating the server multiple times with different configurations
using a newly created workspace
reinstalling JBoss Tools
reinstalling Eclipse
using different JDK versions
I'm really at a loss here and I don't know how to proceed in resolving this issue. Please help.
If you are using Windows, the path could get too long and can cause this error. A simple fix is to move WildFly closer to the root.
I had the same problem and solved it like this:
First of all, stop Server (Servers->WildFly(rigth click)->Stop), than clean. So you can run server again.
I had this problem several times in my new windows 10 machine that my employer gave me. Since I did not have admin rights it was a hectic process to troubleshoot this issue. Simple fix would be moving JBOSS_HOME closer to root. However, you need to do a proper restart of your eclipse. I rather recommend a complete restart of your computer because after all you are going to change JBOSS_HOME in windows environmental variables.
This is related to permissions issue on wildfly folder. Allow full control to the wildfly folder.
https://issues.jboss.org/browse/JBIDE-18697
I have moved the wildfly home to reduce the overall path length, and also removed any non-alphanumeric characters from the folder name (like "-" and "." ) . This worked for me, everything else (removing tmp, deployment, rebooting wildfly, rebooting eclipse, rebooting computer) failed.
I also suspect that the issue was stemming from running Wildfly from a ConEmu and/or git bash shell. Running from a plain CMD shell seems more robust.
I also got stuck with the same problem. I tried the below steps and it worked:
Clear the deployments and tmp folder in standalone folder in wildfly folder.
Delete the server and again add the server
Make a build of the project and start the server after successful build.
This is a terribly annoying error that either the Eclipse team or Redhat need to fix.
The solution is to close Eclipse, right click on the icon -> Run As Administrator. This solved it for me.
I am using VS2015 to start my web application. I would like to be able to run IIS without it if possible to be able to use my app and work with atom or vscode when i want to.
I found the documentation here : http://www.iis.net/learn/extensions/using-iis-express/running-iis-express-from-the-command-line
and came out with (I did not specified the site name because it is the first in my config):
iisexpress -config:C:\Users\myuser\Documents\Project\TempProject\.vs\config\applicationhost.config
It work fine but when I start the server this way, credentials are required when it is not the case when started from VS2015. To my understanding both VS2015 and this command should run the same thing since they both use the same applicationhost.config.
What am I missing to use it with window authentication like vs2015 seem to do by default.
Thanks
I've been writing up a script that runs some server functions using a web-browser interface. I coded up the script on Windows 7 with Internet explorer 8 and it works fine.
As soon as I move it to the production server running Windows 2008 with Internet Explorer 9, it breaks. Finally traced it the point of failure, but I'm a bit stumped how to fix it.
Here's the code that will cause an issue:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("http://www.google.com")
$ie.visible = $True
$doc = $ie.document
$Object1 = $doc.getElementByID("pocs")
This pops up an IE windows, and it should be able to search elements by ID. Trouble is, now I get the error
"Cannot find an overload for "getElementById" and the argument count:
"1"."
I can find very very little on this error. The actual issue is actually the variable $doc. If I do a "$doc | get-member" on IE 9 I get:
TypeName: System.__ComObject#{c59c6b12-f6c1-11cf-8835-00a0c911e8b2}
But under IE 8 I get:
TypeName: mshtml.HTMLDocumentClass
So, basically, IE 9 / Windows 2008 is failing to load the web document contents when I call $ie.document. I've tried setting IE9 to compatibility mode, but no luck there.
The $ie.document | get-member does actually show the method of : "getElementById Method Variant getElementById () " so it's in there, but there's no document for it to parse.
Any ideas would be greatly appreciated.
I am equally astonished this has not been fixed yet given the longevity of the issue on various technical forums. However I think I have found the solution, though it would be up to the Microsoft IE team to address at some point.
Like all the threads referenced that have looked into this I have suffered the same issue with the getElementById method, which with no other changes to a couple of test machines (one Windows 2008R2 Enterprise 64bit and one Windows 7 32bit), I can get the same script to work.
Workarounds that worked as temp solution that I didn't like:
Using the dev console in IE11, switch the Document Mode to 8 (9,10,11,Edge (default) don't work) - my automation script works instantly. No changes to IE trusted sites, zone security, protected mode, PowerShell session priveleges). So clearly just a component issue of the IE11 installation of some sort
Installing Office 2013, without ever running or licensing it, the same script works instantly without changing the Document Mode of IE11. Clearly Office does install/register something that fixes the problem (as Rhys Edwards says)
So I set about narrowing down what Office does to enable the COM object required for IE automation by:
Preparing a new Virtual Windows 2008R2 Server , no updates. Ran test script under IE8 - no issues.
Upgraded to IE11. Ran test script - failed as usual.
Took a VM snapshot
Used Regshot to do record the registry and file system
Ran the Office 2013 Pro_SP1 installation, no changes to default options
When Office install completes, did not run office once (at all ever)
Ran test script again - everything works, the IE automation with getElementById calls all back in operation
Took a 2nd VM snapshot
Ran 2nd scan with regshot and analysed the differences
Dumped the properties of my $ie object and also noticed there is far more there than before running Office install. References mshtml.dll and HTMLDocument classes throughout - looks as it should
I can see from the RegShot difference file that MSHTML.dll is ADDED and registered in the GAC (version 7.0.3300.0) by the office installation
What I did next may not be completely approved but:
I located the microsoft.mshtml.dll in the "c:\program files(x86)\Microsoft.net\primary interop assemblies" folder and saved it out of the VM to my local machine desktop
reverted to the pre-office 2013 snapshot
copied the microsoft.mshtml.dll into the VM and installed to the GAC (remember this is a 2008R2 server still on .net 2, I didn't update .net prior to or after IE11 install, only office). I installed to the GAC simply by dragging the file into the c:\windows\assembly view in explorer. In later versions of .Net you need to use gacutil /l
Tested the same script and BOOM, it all works fine. No need to change any IE settings or elevate script privileges or install Office
So to sum up. If you install IE11, to get PowerShell to automate the Document Model, I had to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesn't ensure this happens is beyond me but I think that the IE team need to look into this.
I also think for those where it 'just works' in IE10/11, you must have a product on the machine that has already registered the mshtml.dll in the GAC (perhaps Office, perhaps Visual Studio or some other MS app). Hence why you are not seeing the same problem that definitely exists.
Hope this helps someone - it was driving me crazy!
Andrew
As detailed in the comments on the question, there seems to be three solutions to this problem.
Upgrade to PowerShell 3.0: Version 2.0 is only compatible with up to IE8 when it comes to web-scraping and using IE as an object. However, version 3.0 will work with IE9. You can get it here.
Turn off protected mode in IE: Turning of protected mode for the Internet zone under the Security tab in settings seemed to do the trick for me. There are security implications to this that should be carefully considered.
Run the script in admin mode: Simply run the script in an elevated PowerShell prompt.
The last two solutions come from a different SO answer.
I had similar kind of issue and it got resolved by following below steps:
Check for the Microsoft.mshtml.dll on your machine. It should be available at location C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies. If you don't find it at this location, It might be the case that you don't have this dll and this is the reason you are getting this issue.
Find the dll, and try to load the assembly at run time. You can place the dll at any location on you machine and do it.
Below is the link to a method to load assembly at run time.
https://onedrive.live.com/?cid=21ad54fd70600673&id=21AD54FD70600673%211922
When using a local NuGet server, whenever I try to install an individual package from that server, all I get is this error: "The remote server returned an error: (404) Not Found."
The packages are all there in the filesystem and the feed itself sees all the packages appropriately. I can even browse the package directly!
What am I missing?
I did just upgrade from NuGet server 1.4 to 1.5, but I've seen this happen before. Touching the package files used to help, but that does not appear to be the case now.
EDIT: Actually, I hadn't seen that exact error before...I've seen this one, intermittently, that touching the package tended to fix.
On Windows Server 2008, I was having the same issue. I switched the Application Pool from "ASP.NET v4.0 Classic" to "ASP.NET v4.0". The install-package command worked fine after the change.
sigh...
http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx
EDIT: In case the link ever dies...I am hosting my NuGet server in IIS6, which wasn't set up to properly handle extensionless URLs. And since the semantics of downloading individual packages changed from a direct file link to an extensionless route, I started getting 404s. Adding the wildcard mapping described in the article fixed it instantly.
I've been trying to figure this for a couple of hours...
Checked the IIS logs and discovered that URLScan was blocking the route:
GET /Rejected-By-UrlScan ~/api/v2/package/
URLScan doesn't accept any route not starting with '/'. The best I could do was to remove the URLScan from the list of ISAPI filters for the website in the IIS Manager.
I was having the same issue on Windows Server 2008.
Problem was in my own package MyPackage.nupkg that I saved without version.
MyPackage was visible in PackageManager but it was getting 404 error on install.
Fix:
I saved it with name MyPackage.1.0.0.nupkg (1.0.0 is current version) and problem was fixed.
I had the same problem, srv 2008 R2. Changed the application pool to Integrated from Classic and all works fine now.
My problem was same as image above. I could go to the site on url
http://localhost:3407/nuget/Packages
but not
http://localhost:3407/api/v2/package/{package name}/1.0.0.0
I encountered this error while trying to download Signal-R after update Nuget, however it was just that I had not checked the "Allow Nuget to download missing packages during build" option in package manager settings. Once that was that set it all worked fine again.
It could be this as well -
You are trying to refer to a url like : http://yourdomain/application/nuget/packages
Then you should change it to :
http://yourdomain/application/nuget
This is a common mistake.