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
I made a small console app in VS 2010 and I just published it and went to install it on another pc (Win XP Sp3). The installer made me update the .Net framework, which I did and then when i went to run th second part which actually installs the app I am getting the following modal box:
Unable to install or run the application. the application requires that assembly EnvDTE Version 8.0.0.0 be installed in the Global Assembly cache (GAC) first.
Please contact your system administrator.
What in the world is EnvDTE v8.0.0.0????
This is a tiny app which does a small web call to an api and returns the results. I do make a DB call for a select and and update using some generated code from Codesmith/Nettiers (including enterprise Library). These files are referenced in the app though already.
Any ideas how to fix or work around this?
EnvDTE.dll is, as Zabba said in his comment (not sure why he didn't answer with this) used to automate Visual Studio. For some reason, you have added a reference to this in your project.
Open your solution, look at the References node in all your solution projects, and delete any reference pointing to EnvDTE.
It doesn't normally magically appear in your reference list; you either have to add it, or the project template you used to create your project referenced it, or you added an item whose template added this reference.
I'm trying to deploy a new version of a BizTalk application that contains common orchestrations for several applications (about 20 or so). The new version contains a new orchestration that will be used by several new applications.
When I try importing the msi for the new version I get an error saying:
"Cannot update assembly "[assembly_name]" because it is used by assemblies which are not in the set of assemblies to update.
To update the assembly, remove the following assemblies: "[dependant_assembly1]
[dependant_assembly2]
..."
The BizTalk server is not accessible from a development environment so the application must be updated using the BizTalk administration console. How do I import the updated application without having the remove and reinstall all 20 or so dependant applications?
Thanks
It sounds like you are deploying a new base application with the same version numbers as an existing, older version.
What works for us:
Every time you deploy a new version of your application, increment the version number (since the assemblies are GAC'ed, BTS supports side by side versioning). Any custom assemblies which are changed should also be versioned.
After deploying to your new Application to your local BizTalk, edit the resources to ensure that the correct (latest) versions of all referenced assemblies and bindings etc are up to date (remove old ones, add new ones).
Your common application will now contain both old and new versions of the assemblies. Newer versions of your 'client' applications will use the later version of your base / framework / common application.
Once all dependent applications have been upgraded, you can then remove the old version.
But the real solution seems to be to consider decoupling your applications more, e.g. by using messaging between the applications - this way, you can split out just the schemas as a common reference to the applications.
You can actually hack the deployment process on BT a little bit further than this, if you want to omit the versioning, depending on your access to the actual BT box. (Convince your sysadmin)
If you only have access to the deployment console, stop your dependent applications, remove their reference to the application you want to upgrade, and then deploy over the top, re-add your references and restart the dependent applications. You don't actually have to reinstall.This method is tedious and sucks but it will work. We do this because we have too much in our BT installs to further clutter them with multiple versions of the same app
Here is the hack. You'll need either access to the server (which I know you said you don't have) or the ability to install a service which can receive a dll and preform the below function for you. (I'm thinking you might convince someone to let you set this up) DISCLAIMER, this is not a supported solution and I claim no responsibilty blah blah blah
We do this all the time as we have WAY too many applications to do the first solution. You can slam your newly compiled DLL into the GAC. This NOT recommended by MSFT etc. but we use it in production on servers that have approx. 4000 dlls in the GAC and 1200 BT applications. You'll need to make sure that your metadata is identical i.e. you have the same version, key token etc. and you'll want to have some way of tracking your dlls outside the versioning system (we build a custom deployment infrastructure to do this). Finally once you have pushed your dlls into the GAC you'll need to restart your biztalk services. Make sure you don't have any suspended instances referencing the app you want to redeploy because they will prevent biztalk from pulling a new reference from the GAC when it restarts.
Finally it is important to note that this method will NOT work if your changes require changes in the MessageBox subscrition (things like changes in receive shape filters, correlations etc.) You will also be giving up some functionality in the orchestration debugger if you use this method to change the structure of orchs. The graphic will display the structure of the orchestration when last properly installed but your event list will be correct for the newest version. Finally, if you are replacing schema dlls you want to make doubly sure that you restart services as BT will cache schemas indefinitely.
I have some user controls in the project kept under a folder UserControls.
I'm using one of the user control from that folder in my master page and one on Default.aspx. The default.aspx uses that master file.
The problem is that everything was working fine until something happened and it seems user control is not getting compiled. The user control calls a method from Business Logic which was parameterless before (when everything was working fine) but when I changed it to accept parameters and of course its calls too, it started giving the error. It is still searching for that parameterless method..!! :(
I did tried manually deleting the DLLs, deleting the user controls and again creating them. But nothing worked.
Anyone has any idea what I did wrong or what am I missing??
Try checking the build configuration manager (Visual Studio 2008 -> Build -> Build Configuration Manager). I ran into a similar issue and it turned out that one of the projects I was referencing was not marked to actually build (there is a check box that should be checked to build the assembly). Try changing the assembly version number of the assembly that is creating the issue, rebuild, then check that the version number of that assembly is correct.
I came across this problem and it was due to the fact an older version of my bin-deployed assembly existed in the GAC. Unfortunately there is no way to force DLLs to load from the bin directory if the GAC version has the same version number. See here: Dll in both the bin and the gac, which one gets used?
This one’s a head scratcher. Here’s the deal.
While deploying a beta copy of an ASP.NET application built with Delphi 2007 for .NET to a test server I encountered an odd problem. The application was unable to start because it could not load the correct version of an ADO.NET data provider that I was using.
Only by including a version of the old assembly in the bin directory would the application run. However, I don’t want to be tied to this older .NET data provider, so I am determined to find a solution to this problem.
I originally compiled the project with the .net data provider assembly used as Copy Local, which should have caused Delphi to use a copy of that version of the assembly that I selected when I added it to the References folder in the Project Manager. The actual assembly that I selected was version 9.10.2.0, and that is the version of the assembly that appears in the bin directory, along with the application. However, at runtime the application was trying to bind to an earlier version of the same assembly, 9.0.2.7.
(Actually, this problem occurs whether or not I use the GAC version of Copy Local, so I don’t think this is the issue.)
While investigating this problem I created a new project, and added a reference to the 9.10.2.0 assembly. Still, both the .NET 2.0 Configuration Utility and Reflector showed that the application compiled with a reference to the 9.0.2.7 assembly.
Inspecting the GAC I saw that both 9.0.2.7 and 9.10.2.0 versions were registered. Attempting to remove the 9.0.2.7 version fails, since that version of the provider was still referencing the assembly in the GAC.
I went into the registry and manually removed all references to the 9.0.2.7 provider. I then was able to delete it from the GAC. This didn’t change anything. Removing the assembly from an existing application and then adding the 9.10.2.0 version back, then compiling, still resulted in the wrong assembly information being inserted into the application. As before, creating a new application that referenced the 9.10.2.0 assembly didn’t work, as a reference to 9.0.2.7 was still being inserted into the executable.
I’ve checked the Delphi library search path. I also removed every instance of the old assembly files from the machine altogether (including from the ASP.NET Temporary Files directory). I still got the problem. I tried using Issam Ali’s AppManifest utility to manually adjust the manifest, but apparently it does not support ASP.NET applications in Delphi 2007 for .NET.
So, the GAC no longer contains references to 9.0.2.7, there are no references to it in the registry, there are no paths to the old provider directory in the project or Delphi options dialogs, the old provider assembly is not on the file system, and 9.0.2.7 does not appear in any of the project files. Nor does it appear in web.config, machine.config, or any other file I checked. Nonetheless, Delphi insists on using this version of the assembly anytime I reference the 9.10.2.0 version of the assembly. (Yes, I restarted Delphi, and also restarted the Virtual Machine in which this development was being performed.)
Even after uninstalling the 9.10.2.0 data provider (the older one was already uninstalled), and reinstalling it, adding the data provider reference to an application results in the runtime application attempting to load the old provider (even though no reference to the old provider apparently remains in the system).
I’ve tried other solutions (which are worth mentioning here), but none worked. Anybody seen this? I am going to continue working on this problem, but I’d love to hear suggestions. I just can’t get Delphi to stop inserting the old assembly information into the project.
For grins I’m including the error log from the failure. This log essentially duplicates the information I get from the fusion log. This log is from one of the simple apps I created after removing the 9.0.2.7 assembly from the GAC. Notice that it’s looking for the old version of the provider from the outset.
Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable c:\windows\microsoft.net\framework\v2.0.50727\aspnet_wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TRAINING8A\ASPNET
LOG: DisplayName = Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
(Fully-specified)
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/
LOG: Initial PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
Calling assembly : TestAdsVer2, Version=1.0.3572.17384, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Inetpub\wwwroot\TestAdsVer2\web.config
LOG: Using host configuration file: c:\windows\microsoft.net\framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
This has gone on so long that the comments that I added to LanceSC's answer are no longer showing. But I do thing this is an interesting item that I want to address.
Here's my last two comments to LanceSC
The installation that exhibited this behavior is in a VM that is no longer functioning. Another developer I know experienced this same problem. The solution was to abandon the installation. I feel that something in the installer of the particular version of this .NET data provider left some strange artifact that produced the problem. It does not happen with any other build of this data provider. I am no longer pursuing an answer to this question.
Spoke too soon. A colleague of mine, today (March 5, 2010), encountered this same error, with a slightly earlier version of this same .NET data provider (9.0.2.1). He is now in the same position I was. He cannot run his application with any version of the data provider, save the old one. That assembly was being used as a local copy, and the old version is not in the gac. Using his machine, we ran the run MSBuild with the verbose option. The build worked fine with no errors. Nonetheless, the compile application failed to run, having failed to find the old version of the provider.
Summary
My colleague resigned himself to reinstalling Delphi 2007 (fortunately, he was working in a VM, and had a second VM with Delphi 2007 in which the offending .NET data provider had never been installed. This was also my tactic.
At this point, I have concluded that this problem is not solvable. Nonetheless, I am leaving this question open for another week or so. If no feasible solution is proposed in the next few weeks, I will close this question.
In the meantime, I have asked my colleague to preserve the VM with the misbehaving provider, in order to test any solution or investigation that is proposed.
Delphi 2007 uses MSBuild to perform the actual builds; however, the code in their product that syncs changes between the IDE and MSBuild is very brittle. My suspicion is that the build files are out of sync with the IDE. An easy way to update them is as follow:
Open your registry editor go to
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals
Change the value of ForceEnvOptionsUpdate to 1.
Open the RAD Studio IDE.
In order to confirm my suspicion you need to locate the files that Delphi.NET feeds to MSBuild. They are located somewhere under the current user's profile. You may also want to look at options in the Delphi help to have it do a verbose MSBuild output.
Have you tried grep'ing the Delphi and .NET framework directories for 9.0.2.7 to see if it is in a config file somewhere?
Something like:
grep -d 9\.0\.2\.7 *.xml
Other places you might search:
search the project files for 9.0.2.7
registry search for 9.0.2.7, and a search using the public token
If this app uses the BDP you might also search the BDP config files
I ran into something very much like this, and it drove me absolutely up the wall for days. I had a reference to Oracle.DataAccess.dll that was resolutely stuck pointing at an old version, regardless of what was in the GAC, in the search path, etc. No amount of restarts of modifications to the .dproj files would ever work.
What I eventually found was that the offending piece that was holding on to the old reference was the generated Oracle.DataAccess.dcpil in the C:\Users\Public\documents\rad studio\5.0\dcp directory.
It was over a year old - whatever the case was, Delphi did not want to write over it.
Once I deleted it, Delphi merrily created another one, and sure enough, it now points to the assembly I want it to.
Ugh, frustrating!