Probing is not working Asp.net 2.0 - asp.net

In my application(ASP.Net2.0),need to group the dlls. So that I used probing ande modified the web.config as follows
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;../../../Runtime/Satellite"/>
</assemblyBinding>
</runtime>
It is not working in Asp.net2.0. Please help me

Sorry, probing only works for subdirectories of your app, never in directories "above" you in the tree.
You need to group the DLLs under your app directory (or use the GAC).

Related

Could not load file or assembly 'App_Code' or one of its dependencies.

Problem: I want to deploy modified code into web server. web server is having IIS version set to V2.0. and now I have developed and published code on my local machine with version 4.0. (there is App_code.dll as part of all dll files).
Now whenever I am deploying all files along with App_code.dll I am getting following error:"
Could not load file or assembly 'App_Code' or one of its dependencies.
This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded"
1) My question is how do I build App_code.dll in older version.
2) I tried changing target framework to V2.0 while publishing but then its not working because AJAX functions from other dll are not compiling..
can anyone please suggest what to do to run the site..
Help is appreciated.
Thanks
Sorry about the answers I've given... But try this...
Try adding <codeBase> elements to the application config file to specify the exact location of each dll, and the version of .Net it requires. Apparently this works because <codebase> is checked BEFORE the probing heuristics kick in each time an assembly needs to be loaded.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="sharedlibA" culture="neutral" publicKeyToken="..." />
<codeBase version="1.0.0.0" href="bin\sharedlibA.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="sharedlibB" culture="neutral" publicKeyToken="..." />
<codeBase version="1.0.0.0" href="bin\sharedlibB.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
If that doesn't work try this.
Late answer but, I'm writing this for future viewers.
I had same error after publish the application to the Server.
I figure it out doing like this.
While publish there is configuration in Setting.
In publish section there is option called
Precompile during publishing
you have to check the checkbox and save then Publish. This will takes your code files .vb/.cs and converts them into a compiled DLL files.
In my case it was unchecked.

"The located assembly's manifest definition does not match the assembly reference" on nuget package

So I was persistently getting this error on the System.Web.Optimization package
Could not load file or assembly 'System.Web.Optimization' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I finally found the solution after much trying.
The key was in the Assembly load trace.
LOG: Redirect found in application configuration file: 1.0.0.0 redirected to 1.1.0.0.
Here are the steps I took to resolve the issue. It might be possible to skip some of these but this worked for me:
Uninstall the nuget package
Microsoft.AspNet.WebOptimization.WebForms
Delete bin folder
open web.config and locate the redirection.
It will look something like this:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Optimization" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.1.0.0" newVersion="1.1.0.0" />
</dependentAssembly>
</assemblyBinding>
I removed the entire assemblyBinding section from the web.config.
Finally re-install the Microsoft.AspNet.WebOptimization.WebForms
package and rebuild.
I don't know where this section came from in the web.config but having removed it everything seems to be working once again.

Compiler runtime error after switching solution to VS 2010

we switched recently our asp.net 3.5 solution from VS 2008 to VS 2010 while still wanting it to be in .net 3.5 (as the deployment server runs on 3.5 only)
The libraries are ok, but the web site is causing us problems. The error message we get on every aspx page is like this:
D:\WebSites\.....aspx: ASP.NET runtime error: Could not load type 'Microsoft.Build.Framework.ITaskItem2' from assembly 'Microsoft.Build.Framework, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
I found out that the interface the compiler is looking for (ITaskItem2) is only available in .net 4.0, but it keeps looking for it in 3.5 assembly which is obviously wrong.
We were trying to locate where this discrepancy is originating, but with no luck.
It hinders our work significantly, because the intellisense is not working for asp components, also debugging of the web pages is not working.
But even when this error occurs in VS, the pages work ok when displaying them in browser (using IIS), so this is VS-only problem.
If you have any idea, what could be wrong here, please let me know.
Thanks
So, I managed to get things right after lots of experimenting.
The solution was to let the VS generate new standard web.config for web site and adding the few extra options we are using into it..
There are only 2 differences between the old and new web.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
was changed to
<runtime>
<assemblyBinding appliesTo="v2.0.50727" xmlns="urn:schemas-microsoft-com:asm.v1">
Not sure if this affects something.
But what seems more important, in the non-working web.config there was one additional section in <runtime>:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework"
publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="3.5.0.0"/>
</dependentAssembly>
</assemblyBinding>
I am not a web.config guru and I do not see what's wrong with the provided section, but without it the things started to work miraculously.

Running web application from bin\debug folder

I'm trying to configure IIS to look for DLLs in the bin\Debug directory (as opposed to the bin directory). I tried updating my web.config, with the following line:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin\Debug" />
</assemblyBinding>
However, it still doesn't see that directory. Is there something else I am missing?
That's only for secondary assemblies. Jeff Atwood has blogged about it. You cannot entirely replace the bin folder. It just allows you to define an additional probing folder.

Set location of DLLs to load in web.config

Is it possible within the web.config to set the local file path location of specific DLLs to load rather than having those DLL in the GAC or C:\Windows\System32.
This would make it much easier to deploy the web service, without having to mess around with either of those.
I have tried already to add the DLLs to the project but with out success. They are the 4 oracle instant client DLLs.
oci.dll
orannzsbb11.dll
oraocci11.dll
oraociicus11.dll
If anyone knows of a way of doing this that would be great.
EDIT:
Please note, note of the DLLs are "strongly named" so I cannot reference them using their public key.
Also, they are not referenced directly in the project currently because they fail to add.
You can use the dependentAssembly element to specify where a dll lives through the codeBase element.
However, I believe this needs to be a valid URL.
Example from MSDN:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
<codeBase version="2.0.0.0"
href="http://www.litwareinc.com/myAssembly.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Probing paths let you specify where an application should look for assemblies. This won't affect putting things in the GAC, but gives you an alternative to storing everything in the bin folder.
http://msdn.microsoft.com/en-us/library/823z9h8w.aspx

Resources