I have a Webpage application which uses in the code behind DLL's and OCX's, some of these DLLs are VB6 ones and the others are C++. At the moment the access to these DLL's / OCX's is through the registy, i would like to change this using RegFree COM.
Problem: All examples i have found until now are demonstrating how to modify an EXE which accesses DLL to Registry Free one using the manifest files, assuming we have one EXE and one DLL the Registration Free access would produce one manifest file for the EXE (in which the dependency to the DLL's mnaifest is set) and another one for the DLL (which references the DLL), in my case i dont have an EXE but a Browser, so i am stuck with the EXE's manifest.
Is it possible to use Registry Free COM in my scenario? if yes where do i set the dependency between EXE->DLL, is it in somewhere Visual Studio??
thank you.
Perhaps you might look at http://www.mazecomputer.com/sxs/help/iis6config.htm which describes the process required.
If you truly mean ASP.Net try http://www.mazecomputer.com/sxs/help/iis6aspnet2.htm
Related
I am working on a large web application implemented in ASP.net. The main part of application, much of it implemented by a 3rd party, is managed by others so I don't have much control over it.
I have implemented 8 ASP.net custom controls which compile to separate DLLs and are put into the application's bin folder. These controls have to link to a couple of DLLs (or should that be assemblies?) from the main application which are also stored in the bin folder. Let's call them MainAppCore1.dll and MainAppCore2.dll. These seem to be managed .NET code.
My problem is that the main application has been updated, and worse looks like regularly being updated in the near future, due to to bugs problems I have compiled all my controls against the original version of the main app dlls, so now they won't load. Obviously I can solve the issue by recompiling all the controls against the new versions of MainAppCore1.dll and MainAppCore2.dll but am looking for a smarter way
My question is: is it possible to keep 2 versions of the main app dlls in the bin folder so that my controls will keep working (probably) each time the main app is upgraded?
I don't want to have to edit the web.config file by the way as this would be politically complicated.
Shortly and Simply, you cannot . Broadly speaking having two versions of .net assemblies in a single folder is only possible in GAC(Global Assembly Cache) folder which is a special folder, where multiple versions of .Net assemblies can run and your control assemblies can point to specific version in GAC, regardless of how many versions exist in there. One possible solution is to ask your 3rd party vendors to strongly name their MainCore1.dll and install it in GAC, every time the version changes, and then in your web.config you can point to a particular version.
Place your 8 custom controls in their own library project and reference that project from the main one. Presumably everything is in source control so there shouldn't be any versioning problems when you do a "Get latest".
I noticed today that whenever I build a word add in project of mine, Microsoft.Sharepoint.dll is being copied into the bin folder and is subsequently included when publishing.
Is there an easy way to see why this (annoyingly large) dll is being included when publishing?
It isn't referenced directly. There are 3 dependencies in the project page and I've checked all these projects and none of them reference it directly either. Do I need to continue following the dependencies of those projects too?
Is there not some kind of log file for a build that could give me a hint?
EDIT:
The problem was that my project referenced a project that referenced a project that had a reference to Microsoft.SharePoint.dll with copy local set to true. I had to delete the dlls from all projects and rebuild with copy local set to false. I didnt realise that the 3rd party dll would be copied into my project.
If this is being pulled in due to a dependency from another DLL, then try looking at all of your DLLs in Dependency Walker. It finds all of the dependecies that a dll has. This is usually only when they are actually being used/bound, but you can also use the Fusion Log Viewer to see where all DLL binds are being bound from.
You could have a a look at reflection mechanism of asp.net or if not you could run trace using firebug for cross reference on browser ,
we have this problem but can't find a solution. We have an application that references something like 24 dlls. When you invoke the application the very first time (after the application is for any reason reset) it takes 25-40 seconds to start loading contents.
This is what we tried:
1. precompile and publish everything in release mode
2. removing pdbs from bin folder
3. put strong named assemblies into GAC
4. set application to debug = false
Please consider that the whole bin folder is composed by 24 dlls for a total size of 28MB. Just 4 of these dlls are strong named and they are more and less 25MB.
Nothing seems changed. What happens EXACTLY when the application is started is something I couldn't find in any book nor forum/blog/post... What can we monitor more to find where the problem is?
Thanks a lot for your help,
Marco
Looks like you will need to use NGen...
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead using the just-in-time
(JIT) compiler to compile the original
assembly.
Precompile the website for deployment, using fixed names, deploy the solution to the server, and then ngen all assemblies in bin
MSDN article on NGen.
Is it possible for my application to monitor a folder that if we copy a DLL (library) in it, the application will pick it up and link it?
I did a similar thing in C++ back in the days but is it possible to dynamically link a library in .NET?
Thanks
Using reflection you could.
Poll the directory for added files, and then if you find one, load it using reflection and run some Main method inside it.
However you can't "unload" these DLLs unless they are loaded into seperate AppDomains.
Absolutely. See this SO question or consider using the MEF.
Let's say you have a solution with two website projects, Website A and Website B. Now inside Website A's App_Code folder, there is a Class X defined in a ClassX.cs file. What do you do if Website B also needs access to ClassX.cs?
Is there any way to share this file across App_Code folders? Assume that moving the file to a common library is out of the question.
Please please don't use these unholy website projects. Use Web Application projects instead, pack your shared classes into a library project and reference it from all your Web Applications.
Pack your shared classes into a Library (a DLL) and from each site right-click on add reference and select the library that you have created.
With the restriction of "Assume that moving the file to a common library is out of the question." the only way you could do this is to use NTFS junction points to essentially create a symlink to have the same .cs file in both folders.
This is a terrible option though (for versioning reasons)...moving it to a common library is the best option.
Here's the Wikipedia entry on NTFS junction points
http://en.wikipedia.org/wiki/NTFS_junction_point
and here's a tool for creating them
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
I don't believe that there is a way without moving ClassX into a new code library project. .NET requires all an assembly's dependencies to exist in the same folder as the assembly itself, or in the GAC, to be automatically detected.
You could try loading the assembly manually via the Reflection classes, although it's a bit hacky.
The best solution, if you have the time available and the inclination to undertake it, would be to go with JRoppert's solution of moving it to a web application project. You could then use web references (which work about as nicely as regular references inside VS) to refer to ClassX.
HTH