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).
Related
Good day,
I have an application that I developed that transfers files between two machines ("site" and "server"). This application was set to target dotNet 3.5. Furthermore, I am using Renci.SshNet to handle the connections between the machines and the transferring of said files.
The issue that I am facing currently though is that about 70% of the "site" machines do not have a standard dotNet and is also quite old; thus these machines do not support all the required functionality as the external dll makes calls to System.Threading.WaitHandle.WaitOne() and System.Threading.WaitHandle.WaitAny(WaitHandle[], Int32) and other overloads of these methods.
The workaround that I have for this though is to install netfx20SP2 or netfx30SP1, yet I am not in the position to perform this update on all machines as they are scattered across the country and have data limitations (bandwidth and cap).
What I want to do possibly is to embed the System.Threading dll that I have downloaded and then the application should use those classes instead, or alternatively just point the application to use the said dll.
Is this at all possible, or do you have to load the dll into the GAC? And also, will it be possible to "run" this higher version of System.Threading in the application while the system itself is on a lower framework version. Something is telling me that the best bet will be to actually run the service pack installation to avoid unnecessary coding but I'm not sure exactly how to approach this.
Thank you in advance for any assistance / suggestions,
JD
To allow the execution of an application that, let's say, targets .Net 4; while the machine itself only has let's say, .Net 3.5, installed, one can redirect Windows to check the local (executing) directory for dlls that should contain the required symbols loaded into memory instead of the default symbols that get loaded upon execution (the default would be the NetFx installed on the machine - which I believe the highest version of the framework that can be found upon loading when the execution starts or would be the highest available version that is lower or equal to the targeted framework).
This file's contents (myApp.exe.local) are ignored. It is just there to tell Windows to
look in that folder for the applicable symbols and if not found, the system will roll back to attempt to load these symbols from the NetFx directory.
Read more at Microsoft Dev Center - Docs (link is attached to the following paragraph which is a Copy-Paste of a section of this document).
To use DLL redirection, create a redirection file for your application. The redirection file must be named as follows: App_name.local. For example, if the application name is Editor.exe, the redirection file should be named Editor.exe.local. You must install the .local file in the application directory. You must also install the DLLs in the application directory.
I have a MVC3 Web Application project that I develop and publish from Visual Studio 2012. This was recently a VS2010 project that was migrated.
My web.config is setup using a <location inheritInChildApplications="false"> tag so that a child application running in a virtual directory does not take on the settings.
I have setup a WebDeploy publish profile, which worked flawlessly in VS2010, but breaks my application when published from VS2012. It adds a <connectionStrings> node after the closing aforementioned </location> tag, even though I already have a <connectionStrings> node inside my <location> node. This breaks the app due to an invalid configuration file.
I've tried re-creating the profile from scratch which didn't solve the problem.
Based on what I have read here, http://msdn.microsoft.com/en-us/library/dd465337.aspx, unchecking the "Use this connection string at runtime" checkbox should instruct the publish process to NOT add the connection string, but it does anyway.
I'm thinking that this would not be an issue if I wasn't using the <location inheritInChildApplications="false">, because the connection string would get added to the right spot.
Also, note that if I publish to the File System instead of using WebDeploy, the published Web.Config is created correctly and does NOT have the extra connection string node added.
Are there any known workarounds for this issue?
As I suspected, this issue is related to the inheritInChildApplications attribute. It is likely a bug in the Visual Studio 2012 Web Deploy whereby the deploy process always adds the connection string to the configuration file, even if you tell it not to. In my case, it was also adding in the wrong spot, which broke my application.
To fix the issue, I simply stopped using the attribute and turned off configuration inheritance using one of the options listed here.
I can now publish without errors, but the process still adds the connection string to the deployed configuration file. Annoying but not a show stopper.
Can someone please confirm or deny my assumption below and/or offer any alternatives?
My Goal
I'd like to be able to precompile and merge my ASP.NET MVC 4 application (as documented here and here) when one-click publishing to our production environment.
The Symptom
I've got an ASP.NET MVC 4 project in Visual Studio 2012. My Web.config contains various entries that are removed in the Web.Release.config transformation. One of the removed entries is the entire configSections element because we maintain those entries in the production server's Machine.config.
However, when I configure my project to precompile and merge for release publication, I get the following error:
Unrecognized configuration section [our custom section name]
My Assumption
What I assume is happening is that it is precompiling everything locally before publishing to the production server (which makes perfect sense) but that part of that precompilation process is to resolve and validate the entire .config chain, from the project's Web.config up to my local Machine.config (which doesn't make much sense, practically). And since my local Machine.config does not declare configSections (or any of the other settings we rely on the production server's Machine.config for), the resolved Web.config doesn't validate.
And since the Web.config doesn't validate, the site can't be precompiled and so nothing is ever published to production.
The Rub
If that is indeed what's happening, then we won't be able to precompile, because the only solution I can think of (other than some potential configuration option I haven't been able to find) would be for all of our developers to have local copies of our production server's Machine.config on their machines. And that simply isn't reasonable because it defeats the whole purpose of having those common settings declared in a single location.
I'm currently working on an shared library based on mono, where I want to put as much business logic of my app as possible.
I used this helpful tutorial.
I managed putting the whole logic for rest-requests in this shared library, but now I'm stuck with soap.
I used the wsdl command of mono to generate Client Stubcode from my wsdl (as described here http://www.mono-project.com/Web_Services).
When I put the generated class to my C# library, which is the root project of my shared library, there is a warning that the Reference to System.Web.Services cannot be found.
So I included the System.Web.Services.dll manually.
For the Android Library Project I added a Reference to ...\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\System.Web.Services.dll. It compiles without warnings.
But now it comes to the Windows Phone Library Project.
There is no System.Web.Services.dll for WP 7.5, right? I tried with the Mono-Touch dll but it gives me a lot compilation Errors.
Someone knows how I can get out of this?
I actually had some issues with the generated WSDL myself. Turns out that the classes that were generated through the "Create Web Reference" piece of Visual Studio inside of a Mono for Android project ended up causing some big issues when connected to a WCF Web Service. Not sure where I ran into this information, but this is what I ended up doing.
What you need to do is manually create a Service Reference using the SILVERLIGHT SVCUtil.
On my development system it was located here:
C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Tools
I called it with the below command line:
slsvcutil.exe http://localhost/<path to WCF service endpoint>/service.svc /directory:"<temp directory to store generated cs file>" /noConfig /namespace:"*,<Full namespace of the generated class>"
That will actually generate a CS file that is saved into the path specified by the /directory tag above. Copy that generated cs file to your project directory and then include it in the project.
The problem that I was having that forced me to look for another option was that I was able to pull the data properly using the WSDL generated through the "Add Web Reference" option in Visual Studio, but as soon as I tried to pass the data back up the wire to the web service, everything blew up. Using the Service Reference generated by the Silverlight Service Util actually generated all the code properly for Async operations and after learning how to properly manage those Async operations everything works like a dream.
Since you are generating this new WSDL using the Silverlight Utility, it should work just fine through Windows Phone 7. I believe that the DLL to reference for all of this is the System.ServiceModel dll.
I wish I could remember where I ran across this information, as I would like to give the original author credit, but unfortunately, I don't recall that.
Hope that helps out!
Chaitanya Marvici
I have an ASP.NET MVC 2 application.
Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.
It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).
Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?
I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
None of these answers are sufficient in my mind. This does seem to be a genuine bug. I will update this response if I ever find a non-hack solution, or Microsoft fixes the bug.
Update:
Doesn't seem promising.
https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I am having this same problem (different assemblies though). If I reference the assemblies in my web project, then they will get included in the publish output, but they should be included anyway because they are indirect dependencies:
Web Project ---> Assembly A ---> Assembly B
On build, assemblies A and B are outputed to the \bin folder. On publish, only assembly A is outputed to the publish folder.
I have tried changing the publish settings to include all files in the web project, but then I have files in my publish output that shouldn't be deployed.
This seems like a bug to me.
I had the same problem with VS2010 and a WCF Service Application.
It turns out that if your (directly or indirectly) referenced DLL's are deployed to GAC, the VS publishing feature excludes them. Once I removed the assemblies from GAC, publishing feature started working as expected.
I guess VS is assuming that if your assemblies can be located in GAC on the machine you build, they will be located in GAC on the target machine as well. At least in my case this assumption is false.
My tests show that the external assemblies get published when I have a reference on them in the web project. I do not have to write any dummy code to make it work. This seems acceptable to me.
I agree with Nicholas that this seems to be a bug in visual studio. At least it escapes me what the reason for the behavior could be.
I have created this issue as a bug on Microsoft Connect. If anyone experiencing it could vote it up https://connect.microsoft.com/VisualStudio/feedback/details/637071/publish-web-feature-not-including-all-dlls then hopefully we'll get something done about it.
If you go into the ExternalAssembly2 reference property list and change the "Copy Local" to "True" i think that might solve your issue.
I don't know if you are watching this still but I found the solution (I had the exact same issue) via this MSDN article. Under "build action" for the file choose "Content" that should include it in the list of files publish brings over.
I have created a new Connect bug here https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I've also attached a solution and detailed steps to reproduce this issue. Lets hope this time they won't close it as Can't Reproduce.
Vote for this connect issue if you experience the missing dll problem.
Copy local did the trick. I had an issue that the Newtonsoft.Json assembly get included in the deploymeny package. Copy local was set to false.
I am experiencing the same type of issue with a web project. I have a web project that references assembly A which references assembly B. It worked fine for some time but today it was broken. I did a rebuild of the solution and this time it deployed everything correctly.
I had this same problem today. I published my web project and realized that not all of the reference DLL's were there. In particular, the indirect DLL references.
It turns out that the directory in which I was publishing to was out of disk space (network share). I had just enough space to publish all the files except for few indirect reference DLL's. The sad part is that VS08 didn't throw any errors. It just published the files are usual. I cleared out some HDD space and everything worked fine.
I didn't find the HDD space issue until I tried to manually move the DLL's over.
in my case it is quite tricky.
Reference to ExternalAssembly2 is not required to Build the project but vital for run-time since we use reflection to configure Unity container.
So, I delete the reference - build the project successfully, but get run-time error.
If I preserve the reference I can Build and Run the application but I cannot Publish it with ExternalAssembly2 - get run-time exception as well.
This is happen because of internal VS2010 assemblies optimization.
So, what we can do here?
1. Put some unrequired peice of code to use any ExternalAssembly2's class.
2. escape from reflection and use static assemblies linking.
Hope this helps to smbd.
I got the same problem and this is a VS2010 bug if there's a reference link like:
Web Project --> custom project --> assembly1 -->(indirectly) assembly2.
For now I find if I reference the Assembly1 in the web project, then assembly2 is included in the bin folder.
So I had to add an additional reference link like:
Web project --> assembly1 -->(indirectly) assembly2.
Then VS can recognize assembly2 and include its dll file in publish action.