I have an asp.net2 WebForms project which worked fine, including referencing a dll compiled for .Net2.
Problem is that I have now recompiled the dll for .Net4 and have also 'upgraded' the VS2010 asp.net WebForms project to .Net4 and the asp.net WebForms application won't access the dll.
The first time the dll is called I get System.NullReferenceException: Object reference not set to an instance of an object.
The new dll is accessed by other WinForms applications OK.
Whatever the problem is, VS2010 freezes and I need to use Task Manager to close it down.
I've searched and can't find anything that even remotely points to what the problem might be.
The problem was in the dll's protection system. In effect, the dll was corrupted.
It is disappointing that no error events were raised to indicate a read error rather than just returning null.
Related
I understand that references are stored in the project (vbproj) file for ASP.NET web applications and the Web.Config (http://msdn.microsoft.com/en-us/library/37e2zyhb%28v=vs.71%29.aspx) for websites.
I have recently converted a website into a web application. I notice now that the web application will publish (using the Publish option) even if the version information is incorrect in the Web.Config, then when accessing the web application through a browser I get an error.
I was unable to Publish a website if the version of an assembly in the Web.Config was incorrect.
I read that web applications are precompiled (before publish) whereas websites are compiled the first time the website is accessed through a browser.
Therefore, I believe what I have said should be the other way around i.e. I should be able to publish websites with an incorrect version in the Web.Config (because they are not compiled) and I should not be able to publish a web application.
What am I missing?
After some further research; I have discovered that ASP.NET web applications are built using MSBuild and ASP.NET websites are built using ASPnet_Compiler.
ASPnet_Compiler looks in the Web.Config for referenced assemblies (add assembly tag) at build time, whereas MSBuild looks in the project file (vbproj) at build time.
Web applications are deployed without the vbproj. I believe the project file is used for linking. Therefore at runtime a web application uses the information in the Web.Config to identify assemblies to look for in the local bin folder and then the GAC (for aspx pages only)i.e. namesapces still have to be manually imported into the code behind partial classes.
If anyone has any comments or better answer then please post.
Got some strange problem.
I'm developing some complicated Web Services network that uses some VB6 .dll. In my previous post I got some problems with the dll but we've solved them.
So, the new problem is:
When I debug my service (those which uses VB6 dll) on development server from visual studio - everything works fine, the problem starts when I publish my service on IIS (I tried my local IIS). After that, when I call .dll method (as I understand I need to call it by reference - and that's what the compiler tells me) I got an exception:
"System.Runtime.InteropServices.COMException (0x800A000D): Type mismatch at ..."
Actually is happens here in the third line:
Object s = (Object)OrderId;
Object s1 = (Object)lines.Length;
proxy.OrderRead(ref s, ref s1);
OrderId and Legth are integers.
As I understant this is exception that comes from the .dll from vb6 :/
What the problem may be? Why it runs when debugging but fails on IIS?
When debugging in vb6,the IDE will register the dll for you. After publishing, have you may ahve to register your vb6 dll on the server. Open a command prompt and change to the location of the dll and run regsvr32 myvb6.dll.
Also, check these settings.
http://support.microsoft.com/kb/281630
In a website project targeted for the .Net Framework 3.5 I occasionally get an error like the following:
The type 'ASP._myetc_master' exists in both 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\site\3a65eca7\73f2d86b\App_Web_myetc.master.cdcab7d2.iefhoqis.dll' and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\site\3a65eca7\73f2d86b\App_Web_myetc.master.cdcab7d2.tgrvlldi.dll'
This error often pops up after updating a backend library that the data access layer for the site relies upon, and crops up in pages that rely on those objects. I have removed the Temporary ASP.Net Files folder in question, and have also removed and re-added the references in question and deleted the contents of my /bin directory. None of those things seem to have any effect (although the last time I encountered the problem clearing the references seemed to resolve the issue).
I only encounter the error when building in the Debug configuration - when building in the Release configuration the error doesn't occur.
Any pointers to where else I might look for a cause or solution would be highly appreciated.
OK, I think I resolved it. Here's what I think the scoop is:
My solution is structured so that I have a data access layer project that references an integration layer with our ERP system. The web project references the data access layer. I had the integration layer also referenced in the web project, so in essence it was being included twice; once by the DAL and once by the web project. Removing the reference at the web project layer resolved the issue.
I am still a little confused as to why the error message pointed to duplication in a master page and not in the objects provided by the integration layer. I am also confused as to why the web project built fine when in Release mode but not in Debug mode. Nevertheless, my specific problem appears to be resolved.
I want to update a class library (a single DLL file) in a production web application. This web app is pre-compiled (published). I read an answer on StackOverflow (sorry, can't seem to find it anymore because the Search function does not work very well), that led me to believe that I could just paste the new DLL in the bin folder and it would be picked up without problems (this would cause the WP to recycle, which is fine with me because we do not use InProc session state).
However, when I tried this, my site blows up and gives a FileLoadException saying that the assembly manifest definition does not match the assembly reference. What in the world is this?! Updating the DLL in Visual Studio and re-deploying the entire site works just fine, but it is a huge pain in the rear. What is the point of having a separate DLL if you have to re-deploy the entire site to implement any changes?
Here's the question: How can I update a DLL on a production web site without breaking the app and without re-deploying all of the files?
The thing to remember is that there are web sites and web applications as far as Visual Studio and ASPNET is considered.
Web Sites typically have all of the aspx and vb files published to the live server and ASPNET Worker Process recompiles the app every time before presentation.
On the other end is the web application, where all of your code behind files get compiled down to a single DLL file and you simply deploy your aspx pages and you bin folder with the DLL file to production.
There is also a "hybrid" known as "Precompiled Web Sites" (see the link for the official MSDN overview) where you don't have the single DLL layout of a web application, but all the compile work of the website is done for you. There are several "modes" to this depending on your needs.
It seems to me that your error is caused because your site is set up as a web site with some kind of precompilation in place. Using the pre-compiled model is a little more "strict" in that is assumes certain files/signatures are in place. Having an updated version of the DLL file causes a break since the precompilation wants a name and a version of the file.
If possible, your best bet would be to convert to a web application, since you can add the additional DLLs into production without a problem. Otherwise, take a look at this matrix to see what form of precompilation you need for your application.
Look at this SO post, might be what you are referring to. The located assembly's manifest definition does not match the assembly reference
Have a look at your reference. Does it say "specific version = true" ? Set it to false, republish your app (you have to do it once, because now your app is still looking for an assembly with a specific manifest) and try it again.
I have C++ project that compiles as DLL Assembly in .NET 3.5 SP1
Project is used for Image rendering processing by using WPF (it loads 2 images from local folder, applies one image on another and saves the output file in the same folder).
I want to use that that project as a reference in ASP.NET project to the rendering on the website.
So I created simple Web Project in ASP.NET C# that uses C++ project as a Reference.
Everything works great in ASP.NET Web Development Server (built-in Web server in VS2008).
But once I publish this project to IIS on the same Machine or use IIS for debug instead of built-in Web server Image rendering it's not working anymore. I'm not getting any exceptions or error messages, it just output image is not processes as it supposed to be.
If anyone know what could cause that I would really appreciate your insight!
Do you have access to the Event Logs? You should check there for any errors. You should try to throw an exception from a C#-only code path and make sure that everything is OK and regular exceptions are being thrown. Is the C++ compiled to managed code, or is native code? You might find that ASP.NET does not have the appropriate code access security permissions and needs to be registered in the GAC of the server to accessed from C#.
You should also check whether the DLL is thread-safe. This has caused issues for other users in ASP.NET/IIS.