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.
Related
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
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
We have deployed a AX2012 model that we developed in our dev environment into a production environment.
The model consists of a C# project, for which the settings are set to deploy to client and server.
After deployment it seems that the .NET assembly for the C# project is generated for the client vsassemblies folder (under c:\user\appdata\microsoft....) but it doesn't generate on the AOS server under C:\program files\Dynamics AX...\Server\bin\Vsassemblies folder".
The hot swapping setting is on. Is there a way to force the regeneration? Even restarting the AOS service doesn't recreate the assembly.
should be something like this:
http://msdn.microsoft.com/en-us/library/gg889192.aspx
"An assembly is copied to the client under these circumstances:
When a call is made from the client to managed code that is contained in the assembly.
When you access IntelliSense (at design time).
When you compile code that references the managed code assembly."
also, there are indications some of the documentation may be incorrect, and a bit of discussion about the server bit:
http://daxmusings.blogspot.com/2011/09/ax-2012-net-assembly-deployment.html
We´ve got the same and many other Problems with .Net Projects in Microsoft Dynamics AX 2012.
Do you use Microsoft Team Foundation Server 2010 and tried to check in and check out those Projects? The Solution Files will have a write lock, sometimes it can´t find the project to open it in Visual Studio... and so on...
I think the Developer Team from Microsoft Dynamics AX have a lot of work. Ah... I forget... Try to rename an already checked in AOT element. First it all looks good. But if another developer get latest changes. "There is already an object with origin id"... Great... :-/
It is really hard to manage a team with greater than 10 developers and many many problems.
I am experimenting adding plugins to CRM2011 server. Following the steps of Plug-in Sample with the sdk, everything worked as expected. However, when I tried to register the plugin to Disk (the default is to Database), I got
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Unable to load plug-in assembly.
Seemed that the server couldn't find the microsoft.xrm.sdk file. But why the same setting worked fine when publishing to Database?
I have added "write" privilege to user "Network Service" for folder C:\program files\MicrosoftDynamics CRM\Server\bin but got same error message.
The Server OS is Windows 2008 R2 Running inside a vmware player virtual machine.
I have got the answer from microsoft forum. Turned out that I need to manually copy the dll over to CRM server under CRMINSTLLDIR/Server/bin/assembly then I can do the registration from my client machine.
Now that I know the concept but still think it anti-intuitive. Is there any reason that Microsoft designed its plugin registration process this way? Security?
If you try adding group "Everyone" with full access to the bin folder, do you still get the error?
One does seem to be stuck with registering the .dll in the CRM database once that selection has been made, so one cannot then start using the assembly folder (disk) after that.
I've sort off gone with always using disk when dev'ing so one can quickly update just the assembly and only use the database option in a production environment.
If you really want to deploy to disk try this:
Create a share on the […]/Server/bin/assembly folder with read/write for just the developer. Alternatively if the developer has admin rights on the server you can skip this step and just use the admin share. For example:
\servername\c$\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
In Visual Studio, under the Project/Properties menu selection, in the Post-build event command line box, add a command to copy your .dll (and .pdb if debugging). The copy command should include either the share name created in the previous step, or the path using the admin$
Also, take a look at the macros available under the Edit Post-build button. You will find some useful bits like $(TargetFileName) to abstract actual file and folder names.
Now every time you build, your files will automatically be copied to the server.
Even though I register my plugin to the database, I use this method all the time. If you want to do any remote debugging you will need the .dll and .pdb in the assembly folder on the server.
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.