Add service reference to Amazon service fails, saying
"Could not load file or assembly "System.Core, Version=3.5.0.0,...' or
one or more of it dependencies. The module was expected to contain an
assembly manifest."
This is in VS 2008, haven't installed SP1 on this machine yet.
Any ideas?
This can happen if ASP.NET isn't installed. Go to Add/Remove Windows Components and look under IIS; make sure that ASP.NET is checked (meaning that it's installed.) That should clear up your problem!
Related
Once a week I get the new version of .net assembly which I need to deploy to our Axapta 2012 installation. I don't want to copy this dll to axapta client folder on each computer. So I am searching the way to deploy it to AOS and hope it will deploy on each client automatically.
I have found many solution (this is one of them), but all of them works only if I have the source code of this assembly. I don't have. And I can not to 'Add VS project to AOT' and deploy it using VS add-ins.
Is there any way to deploy .net assembly (as compiled DLL) from AOS to each client ?
If you cannot do it using the "Add VS projection to AOT" method, you can use the SysFileDeployment class. This is demonstrated in Joris DG his blogpost here.
On msdn the description of the SysFileDeploymentclass is as follows:
The SysFileDeployment class is used for deploying files from the server to the clients.
On msdn it is also explained how you need to do this.Basically all you need to do is extend this class and point to the files you need to deploy (in your case a dll). You will also have to change the build number of you solution to trigger the deployment.
You can also deploy dll's by adding them to the GAC, as demonstrated here:
Axilicious: AX2012 DLL Deployment and how AX binds DLL’s at runtime
To summarize main differences are:
Using the visual studio properties: it is deployed to a folder specific to that user (so a different folder for each user) at the moment it is needed
Using SysFileDeployment: it is copied to the client bin folder, a restart of the client is needed (possibly problems when on citrix/terminal services, like Joris suggests in the link you provided?)
GAC: DLL's are stored in the Global Assembly Cache and different versions are stored but you need to provide a mechanism of deploying them yourself
Personally I would try the SysFileDeployment method as it's the standard method MS provide. If you have trouble, you might receive support.
First of all I publish my website in windows 7 and everything goes alright.
But when I'm trying to publish the same website in windows server 2008 r2 I got this error:
Server Error in '/MyWebsite' Application. Could not load file or
assembly 'System.Net.Http' or one of its dependencies. Strong name
signature could not be verified. The assembly may have been tampered
with, or it was delay signed but not fully signed with the correct
private key. (Exception from HRESULT: 0x80131045)
Can any body help me, please!! I looked for this error for days now and I got nothing to do.
Thanks in advance!
It seems you not copied your dll to your another website in window server 2008 r2
if you already copied .dll to your 2008 iis then ..
First check
Both are system are running in same 64bit or 32bit ?
If not then
1.Open IIS Manager
2.Select Application Pools
3.then select the pool you are using
4.go to advanced settings (at right side)
Change the flag of Enable 32-bit application false to true.
Another solution
1- check if you are referencing an assembly which in turn referencing an old version of unity. for example let's say you have an assembly called ServiceLocator.dll which needs an old version of Unity assembly, now when you reference the ServiceLocator you should provide it with the old version of Unity, and that makes the problem.
2- may be the output folder where all projects build their assemblies, has an old version of unity.
you can use FuseLogVw application to find out who is loading the old assemblies, just define a path for the log, and run your solution, then check (in FuseLogvw) the first line where the Unity assembly is loaded, double click it and see the calling assembly, and here you go.
There are many other possibilities..
I've created a small Class Library, with a HttpModule that uses a filter to add some html to every requested page served by IIS7.
I tested it first by registering the module in the web.config in a test web site, and it works as it should, but only in that one application.
I generated a dll, and created a strong named assembly.
I need to somehow add this assembly as a module in IIS on a server level, so that it works for all requests, on all applications, and for non-asp.net content as well.
So far, I have tried adding the .dll as a native module. This doesn't work. It's on the list of native modules, but it doesn't work.
I have installed the .dll in the GAC.
Reading on, it seems I have to add the assembly as a managed module, and then choose it in the dropdown list under "add managed module" in IIS.
For this, I tried using the commandline tool appcmd, writing: "add module /name: string /type: string /preCondition: string"
I've had no success doing this, since I can't figure out what to set as type and precondition.
As I have read, the modules registered in IIS should work for all applications in all sites, and all requests.
The point is to avoid having to register the module in every applications web.config file.
Any ideas?
After working with this for a bit, I managed to make it work.
Installing the assembly in the .net 4.0 GAC will not make it available in the type dropdown in IIS manager under "Add Managed Module".
What I had to do was:
Create the .net 4.0 Class Library, and compile it as a strong named assembly
Install it in the .net 4.0 GAC by using the gacutil, located in Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools
(Or make Visual Studio compile, sign and install the assembly automatically)
Add this line under <modules> in applicationHost.config: (it has to be done manually, it can't be done in the manager)
<add name="MyName" type="NameSpace.ClassName" preCondition="managedHandler,runtimeVersionv4.0" />
This makes the module run on requests to sites developed in .net 4.
It appears, however, that requests to sites developed in pre .net 4 versions can't use a module created in .net 4.0. So if you make requests for pages in a site created in .net 3.5, the module will not work.
Another observation:
After you have added the module to IIS via the applicationHost.config file, if you open the IIS manager, highlight the servername in connections and click modules. You will see the .net 4 module on the list.
Double click on it, and you'll then see the settings for it. You'll see that the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox is checked. If you uncheck it, and hit ok, you'll get an error saying that the assembly hasn't been installed in the GAC.
But didn't I just install it succesfully in the .net 4 GAC? And didn't I just see the module run in a request?
If you go ahead and save the settings anyway, you get a runtime error, and if you look in applicationHost.config, you'll see that your previously manually added module settings has changed.
But what if I want to "Invoke only for requests to ASP.NET applications or managed handlers?
I am now able to run the module on every request. The reason it didn't work before was a totally un-related error on my part.
So, the steps involved to make it work is:
Write the code you want to run on every request, as a .net 3.5 Class Library.
Compile it as a strong-named assembly.
Install the assembly in the GAC.
In IIS7 manager, select the server name in connections, click Modules, click "Add managed module" in actions.
write a name for the module and choose your newly installed assembly in the type dropdown.
Make sure the site uses an application pool running in integrated mode.
Of course, it's not always a good idea to let all code run on all requests, so you may need to filter some of the requested files.
One question remains though!
There are now two GAC's, Microsoft.NET for .net 4.0, and Windows GAC for pre .net 4.0.
Because I created my assembly in .net 3.5, it was installed in Windows GAC, and therefore it was available in the type dropdown in IIS manager.
When I created my assembly in .net 4.0, it was installed in the Microsoft.NET GAC, and as a result, it was NOT available in the type dropdown in IIS manager.
The question is: How do you add a .net 4.0 assembly as a managed module in IIS7, and have it run like my 3.5 managed module?
This must be possible, right?
You have to add a module at a server level. You can do that from command line:
appcmd add module /name:string /type:string /preCondition:string
To get command line help execute: appcmd add module /?
In short, it must look like:
appcmd add module /name:AnyNameOfYourChoice /type:YourClassNameSpace.YourClassName
/preContition parameter is optional.
More details here.
OR
Do it from IIS Manager by going to server node -> Modules -> Add Managed Module
More details here. (bottom of the page)
I just tried to copy my entire web application to a new instance of Visual Studio 2008 on another (virtual) machine.
It builds just fine, but when I try to run the applicaton I just get the message "The specified module could not be found".
Does anyone have an idea how I can find out which module this message refers to? Because there are quite a lot, and as far as I can see they're all installed.
I would suggest you delete all the temporary ASP.Net files for your project and then do a rebuild. This will ensure all the new code is recompilled and no old references remain.
Sometime simply building the solution doesn't work and you need to rebuild instead to force it to either show you the real error or get the references correct.
If your project uses COM and an interop assembly, you'll be able to build (because the assembly is there), but raise a runtime exception if the COM server is not registered on the new machine.
I have a DLL which is GAC'ced (c:\windows\assembly) which is being used by my Biztalk Application, for some requirement, I changed a function in that DLL and:
I uninstalled the old DLL which was in GAC (version 1.0.0.0)
I GAC'ced the newly built DLL into GAC (version 1.0.0.0)
I also restarted the BizTalk Host Instances.
But still the output seems to be from the old DLL's function. I am not getting the problem, why still I am getting the old output.
Can anybody help me?
Some tips that might be helpful:
(1) If you have multiple BizTalk servers in your group, be sure to update all of the servers!
Depending on your host instance configuration, your instance may run on any server the host instance is active on.
(2) Make sure you restart the correct biztalk host instance. This is often overlooked. Don't forget about the BizTalk Isolated Host! Perform a recycle of the specific IIS application pool if necessary. If you are unsure, perform an iisreset.exe
(3) To update a DLL in BizTalk it is often necessary to update it in the BizTalk database as well. For some changes it may work just updating the DLL in the GAC, but often I find that this is not enough (especially with orchestrations).
What you are describing here is correct. You should see the new DLL taking over. A couple things to check:
Did you recycle the correct host instances?
Did you recylce the host instances on all servers?
Did you veriiify the Create date on the GAC'd DLL to ensure the new one was installed?
Another issue might be based on what you changed in the Application. You can only Gac/Restart under particular circumstances. See this When can you just re-gac and re-start on Jon Flander's blog for reference.
If you want to be really sure that the correct assembly that has been GAC:ed, click "Run" and type "%systemroot%\assembly\gac" for .Net 1.1 or "%systemroot%\assembly\gac_msil" for > 2.0.
There you have the physical files for each version number to be checked (or overwrited).
It might help us support you if you let us know what part of BizTalk you are using the assembly, pipeline, functoid, schema etc.
Is that DLL used under a BizTalk process (BTSNTSvc.exe) or by an Isolated Host Instance?
If this DLL is used in a Receive Location which Receive Handler (Host) is Isolated, for example a SOAP Receive Location, you have to restart the Application pool from IIS and not the Host Instance.