My question may have already been asked but any of the answers match my case.
I need to do a website (ASP.NET MVC 4) with some features of a software. I have finished to developed my website and wanted to test it in a test environment (Windows server 2008 - 64bits).
It works perfectly fine with my dev computer(windows 7 - 64bits). But after I deployed it on IIS, one of my features doesn't work.
This feature is a bit particular. It need a 32 bits COM written in VB6 (this dll can't be change) that call an other dll. When I test the website deployed on IIS, the first ddl is called fine but the 2nd seemed to be not called at all.
This dll are in the installed file of the software. I have the same version of on both computer.
I authorize my app pool to use 32bits application. I tried to give some access to my dll (the COM and interop) like IUSR, IIS_IUSRS. But nothing seems to work.
I have checked both of my dll are registered properly.
I'm a bit lost. Can someone help me ?
PS: Sorry for my English, I can speak but I'm really weak with syntax.
Some suggestion here:
You need to figure out which managed dll, native dll and lib files are referenced by your application (directly or indirectly).
For managed dll, make sure they are in the web's bin folder.
For native dll and .lib files, check out whether those .dll and .lib files are in the PATH. If not, you can either copy them to there; or, you can put them into a folder and add that folder into the PATH. Then restart VS and IIS (command "iisreset") to make sure the setting is picked up.
By the way, putting all of the files in the web's bin folder won't help. The reason is CLR copies the files into a temporary folder under framework directory and run the web there, but CLR only copies away managed dll (not the native ones), so you still get "module not found" error.
I have reproduced this error using the following sample solution
Web1 references a managed c++ project say "MCpp1.dll". The project further references two unmanaged c++ projects with the output say "Lib1.lib" and "Lib2.lib"
If I copy all of those files into web's bin folder, I get the exception of "module not found error".
I create a folder say "C:\Lib" and copy "Lib1.lib" and "Lib2.lib" into it and add this folder into PATH. I restart VS, and also run "IISReset" since I have a IIS web
Open VS and request a page and it works now
I have also contacted the CLR/Fusion team for suggestion of how to get the related module name when this exception happens, which should be very helpful to make diagnosis.
Hope this helps ,
GODFATHER
Related
Our application is composed of mixed C# / managed C++ CLI / native C++ assemblies & DLLs.
We have a wrapper assembly that exposes the application's API.
FOR EXAMPLE...to create new console applications that use the API, you must reference that assembly, and also set the console application's output directory to the BIN directory of our installed application. ( due to the use of reflection, etc., everything must stay in the app's BIN directory and output to that directory, you cannot do a copy local of just the one assembly or nothing works )
My issue is when creating an ASP.NET web forms application (nothing to do with the console app), I would like to use that assembly, so I need the web application to "live" in our application's BIN directory.
When I try that errors occur due to ASP.NET trying to preload every single assembly in that BIN directory.
Can someone provide instructions on how to get this to work? I've spent hours now on every combination of referencing assemblies, copying them all, and trying to use LoadFrom.
Without seeing the construction of this it's hard but ...
Bin referencing
Create a web application and reference the necessary dll from the web site via bin references
Right click the web application, select the browse option and pcik the dlls you need to reference. Select copy local to true so you get the dll copied through to the web application so you aren't forever dependent on the console app being exactly where it needs to be in relation to the web app.
Not a solution I would necessarily go with though - it seems like the arcitecture of the system is a little off. Cross you have to bare etc...
OR
GAC referencing
the dlls that you need to reference from the console app - strongly name them and put them in the GAC (global assembly cache). Both apps will be able to see them then.
Copy over the dll
I guess there is another solution around adding a post build step to the console app that reruns a batch file that will copy over the dlls into the web app. I think that's going to be pretty much the same as the bin reference though really.
Probing element
You could use a <probing> element in your web.config to instruct the CLR to search for other directories for assembles (it normally just does the GAC and bin (a simplification to be fair is that) ). This is going to enable you to reference your API folder - but only if it is under your application path. Although someone here has used an NFTS junction to get around this.
More info here
In fact this answer gives a lot more detail about this kind of thing
How do I reference assemblies outside the bin folder in an ASP.net application?
And good luck
My ASP.NET webpage requires some data provided by a C++ .NET DLL. Everything seemed to work fine as far as loading this DLL and calling functions in it at first, but now my project seems to have gotten into a state where it does not actually debug if I reference the DLL in the .cs file.
I commented out all of the code that references the DLL and removed the reference from my project, and it worked fine. I added a reference to the DLL back in, and it worked fine. I uncommented only the using statement for the DLL's namespace (using MDnlnkCmdReader; in this case), leaving no actual code referencing the DLL, and now, when I hit debug, none of my breakpoints hit. Comment out that line again, and the breakpoint hits again.
When it gets into this state where the webpage appears to load correctly but none of the breakpoints hit, if I switch back to the source code and view the breakpoints, they show up as an outline with a caution flag, and if I mouseover them, then it says "The breakpoint will not currently be hit. The source code is different from the original version"
I looked up that error message too and tried the usual solutions to it. If I nuke the entire /bin folder, then I start getting webserver error messages about global.asax. These persist until I build in Any CPU mode (normally building in x64), at which point I get "unable to load" messages about the DLL (built in x64). When I delete the reference to it, then the page works again. Switch back to x64 mode and add the reference back in, and I'm right back where I started. Rebooting doesn't seem to help either.
Any ideas what's going on here, and how to get out of it?
Okay, I think I have this figured out now. What I have been dealing with is actually two different issues.
The first issue is that the ASP.NET development server seems to only be willing to grab its DLLs from the projects's /bin folder. Your project will build there if it is set to Any CPU, but if it is set to x86 or x64, then the default is to build in bin/x86/Debug or bin/x64/Debug. If you are set to x86 or x64 with the default build locations, then the development server will still try to grab DLLs from the root of the /bin folder.
If you have never built your project as Any CPU, or have cleaned out the /bin folder since the last time you have, then it will not find your DLLs at all, and the development server will display an error message like "Could not load type 'WebDownlink.Global'." about your Global.asax file (where WebDownlink is the namespace of your project). This means that it cannot load your namespace, which is because it cannot find your DLLs because it is only looking in the root of the /bin folder.
If you have built your project as Any CPU and then switched to building it in x86 or x64, then your new build will be in the appropriate subdirectory, but the development server will still grab the files from your last Any CPU build. The Visual Studio debugger will be using the files you just built, though, so if you have changed anything since your last Any CPU build, you will get the different source code error and debugging won't work right. If you haven't changed anything, then debugging will work, but the development server will still be running the Any CPU version, which may confuse the heck out of you if you are trying to do anything where bittedness matters.
The correct solution to this seems to be to configure your x86 mode to build in the root of the /bin folder rather than the /bin/x86/Debug folder. Or maybe don't reference any unmanaged DLLs in the first place.
This dovetails into the second issue, which is that the ASP.NET development server runs in 32-bit mode only, while the IIS application pool on a 64-bit system runs in 64-bit mode only (if you know of a way to change either of these, please let me know). If you need to link your code to an unmanaged DLL that can't be built as Any CPU, you will have to account for this. That's why I only reference x86 above - there's no point in changing where your x64 builds because the development server won't run it anyway.
Luckily, I have the source for the DLL that my code references, and it doesn't reference anything else, so I can easily built it in both 32- and 64-bit mode to run it on both the development server and the full IIS. If you are referencing a 32-bit DLL that you can't rebuild, then you will either have to deploy on a 32-bit machine or figure out some way to get the IIS application pool to run in 32 bit, which I couldn't. If your DLL is 64-bit and can't be rebuilt, then you'll just have to do all of your debugging of code related to it on the full IIS.
So my solution is to build my DLL in 32 bit, reset the reference, and then build in 32 bit mode, with the output path set to /bin. When I want to deploy, I rebuild the DLL in 64 bit, reset the reference, build the project in 64 bit, and then deploy to IIS.
Open up the "Modules" window while you are debugging and take a look at the "Path" column - does the path given for you assembly match an assembly which you know matches the source code?
ASP.NET normally puts copies of assemblies in the "Temporary ASP.NET Files" folder and so it may well be that you need to clear this out too.
Note that you can also untick the "Require source files to exactly match the original version" which will allow you to debug as long as the source code isn't that far out. However, it's probably a better idea that you fix the underlying problem (the assemblies don't match the source) instead.
The situation is I made a minor bug fix to a class, so they want to just deploy the dll affected. They stopped IIS, replaced the dll in the /bin folder of the iis directory for the web site with the new one I gave them, and started iis again. There are multiple servers, but they just changed it on one to try it out. They are still seeing the same error in the eventlog of the server in question. Looking at the stack trace I can tell it is running the old dll.
They've checked the GAC and don't see it there.
I've checked the dll with reflector to verify I gave them the correct new dll.
This is an asp.net 2.0 website and the server is 2003. I'm not sure how it was deployed originally but it has a copy of the old dll in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\NAME_services#################\assembly\dl3###################\ and in D:\xxxx\Sites\NAME\Services\obj\Release. Could it be using one of these or building the old one or even just caching it in memory?
Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.
We had same problem but with minor complications, we have many many sites so a "clearing all temp" and restart IIS is not a good option for us. So we needed to be more selective in what to force a refresh on.
On our QA machine, under ... "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files"
I did a file explorer search for the partial file name of what we are trying to release. The file was found in a folder something like:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\4503212x\ad95664x, so I stopped app pool, deleted the folder, restarted and all was deployed then - great!
But .... We had same trouble deploying to production and the above did not work.
Long story short, the QA app pool was set to "enable 32 bit true", but production was set to "False" so the prod temp files resided in:
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" instead (\Framework64\ instead of \Framework\ ).
If clearing temp files is not working - double check your frameworks, or look for files to refresh at the C:\Windows\Microsoft.NET folder level and below. you may be surprised.
You don't have to stop IIS to deploy your update, you just copy them over.
Also, if they copied only the DLL but your fix was in the .aspx file, then it won't show up. You should really do a full deployment.
We copied the project source code to a new folder and reopened the solution. This somehow tricked Visual Studio into not using the cached version of the DLL. Wish we knew why this worked, but that resolved it for us.
I have built a few custom applications that run on WSS 3 using the Visual Studio 2010 Web application template. When I compile the application, Visual Studio creates the assembly file in the bin directory which I copy over later to the production server (another machine) with WSS 3. The compiled application dll file is copied into the bin folder inside the virtual directory of WSS and runs fine in there.
As the project requirements / applications grew over time I now face the problem that the first hit on the assembly triggers dynamic compilation which I would like to avoid.
Even if applications are running fine I would like to use the asp precompiler on my development machine in order to reduce the delay when the page is first requested.
I have used the following command to precompile the entire Web Application:
aspnet_precompile -v / -p PATH_TO_WEB_APPLICATION C:\WebApp -errorstack
The compilation runs fine without any errors and I end up with a couple of .compiled files and also a Web_App_xxxxx.dll file inside the C:\WebApp\bin folder.
From here onwards I am a bit lost on how to proceed.
Could you please give me some advise to which folder I need to copy the compiled files on the production server ?
Do they need to go into the bin folder on the server or better into the folder where the aspx pages are located?
Additionally I would like to know if I can precompile the Web application on a development machine without the IIS metabase using the -v and -p switch and later use it inside WSS?
I copied all files from the C:\WebApp\bin folder to the server bin folder but unfortunately the csc compilation process still kicks in when looking with process monitor at the server events.
Cheers,
Mathias
The files just need to be dropped into the bin folder and everything will work fine. As for the -v switch you do need to have it if you're using the -p flag, but I think it depends how you're compiling the app too. Check this link out for more. I don't believe its a big deal if its wrong / incorrect though.
This kind of scenario sounds like a job for Cruise Control .NET environment.
I found an answer to this precompilation question:
I thought the first hit on the application page takes a long time because asp.net needs to compile it and I can save some time by precompiling. The application runs inside the WSS context and enables the user to go to a web form and update through the form his/her Active Directory profile. The Exchange global address list is also updated on the Exchange forest so the changes are visible through the Outlook address list and also on Communicator.
The complete solution code with reports etc is around 6000 lines of C# code.
My assumption regarding slow compilation due to the amount of lines was wrong.
I downloaded the following hotfix for asp.net:
http://support.microsoft.com/kb/961884
and set optimizeCompilations="true" in the web.config as explained here:
http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx
http://www.paulliebrand.com/2009/09/18/sharepoint-development-to-bin-folder-and-extremely-slow-render-initial-render-times-solution/
Now the first hit on the application is much faster.
Many thanks,
Mathias
I am building a web application with .NET 3.5. I have several class library projects being referenced by my web forms.
I am deploying using a web setup installer.
When I install the application and hit the opening page, I get null pointer exceptions to some (not all) of the objects in my class library. Looking at the stack trace reveals that something somewhere is looking for a directory that exists only on my development machine.
When I do IISRESET, the errors vanish.
Does anyone have any idea why my application (web.config is compiled with debug="false") is attempting to look for things on my local dev machine?
My active build is set to release.
Thanks.
Did all the .dll's you used in your site get published with your code? If not make sure they are placed in by the installer, and the web config is not hard coded to look for references.
Open Visual Studio, look at the References folder and check to see if any of those references are pointing to the file(s) in your DEV machine. If so, I suggest you add a new folder to your app (i.e. Assemblies) and add all the dlls your application references in that folder.
After that, make sure all the references in your project are pointing to the dlls in the Assemblies folder and not some folder that only exists in your DEV machine.