Is it required to have anything SQL Server related installed on a web server in order to make use of SMO? I've built a web app that programmatically creates a SQL Agent job, adds a step (which ultimately fires of dtexec to run an SSIS package), and executes.
This works fine on my local machine which has SQL client tools installed, however when I move to a web server, I get reference issues and I'm starting to think it's due to something not being installed.
Could not load file or assembly 'Microsoft.SqlServer.SqlClrProvider, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies.
This is a rat hole.
The problem is that once you locate that assembly and copy it to the bin folder of your application it will complain about a completely different one.. or even the same file simply due to missing dependencies.
For more information read this: http://www.sqldbadiaries.com/2010/10/20/how-i-fixed-could-not-load-file-or-assembly-microsoft-sqlserver-smo-version10-0-0-0-issue/
That site lists the files you need and the fact you need to register and gac a few files. Quite frankly, you are much better off just biting the bullet and install the client tools on your web server.
Yes, your application requires this assembly in its bin directory to function. This error means that the server doesn't have the SMO (and its dependant) assemblies.
Back in your solution in Visual Studio, right click on the assembly above, and select/change the "Copy Local" to "True". Copy this for each SMO assembly that you've referenced.
When you publish your application, this will bring those .DLLs on your development machine along in your published bin directory.
Check your web.config file for any references as well
search your code for SqlClrProvider
Related
I am using Visual Studio 2017, and the application target .net framework is 4.5.2.
This application ABC (to which I am providing an enhancement) is already deployed and functioning pretty well.
Now that I have to only perform changes on 1 page (a simple condition change), I am planning to deploy only App_Web_xxxx in the ".\bin" folder.
After publishing the application using the "Precompiled" configuration, I was able to identify the respective App_web_xxx.dll file and copied in App. Server bin folder. Renamed it according to existing requestEdit.aspx file. All looks good till now, and interestingly, this App_Web_xxx.dll is common for multiple aspx files available under a common folder (users/request).
Once I try executing this code by accessing the website (respective aspx.cs UI file), it gives the error:
"Could not load assembly "App_Web_xxx.dll", make sure that it is compiled before accessing the page".
But the issue is This dll file doesn't break for any other aspx page available under the User/request folder, it is failing only for feature I modified.
What I have done apart from above mentioned way (considering usual way of partial deployment process):
Replaced requestEdit.aspx page and added new dll, by keeping old dll as is (which can be used by other aspx pages in deployment folder)
Error changed to:
Could not load assembly 'App_Web_xxx.dll, version=0.0.0.0, Culture=neutral, Publickey Token=null' or one of its dependencies.The system cannot find the file specified.
Replaced requestEdit.aspx page and added new dll, by removing old dll and renaming App_Web_xxx.dll in "Imports = Default.aspx, App_Web_xxx.dll" in all required aspx files (for which the old dll was removed)
If I am replacing the whole solution (except web.config) the solution works fine with no issues, the only problem comes when I am replacing only 1 .dll file.
All the solutions I found are providing information of IIS version or dll copying from Server to Dev, but my problem is I'm publishing on dev env (local machine) and partially deploying on the server.
Need help to resolve this issue as this is really inconvenient to deploy the whole solution just for 1 condition change!
Additional Info:
Page Properties --> MSBuild Options --> Allow this Precompiled site to be updatable (checked)
My (C# Asp.net) website works locally, but when I publish it to Azure, it is missing a dll (OpenXML SDK).
After extensive googling, I found that I should set the Copy Local property to True. The thing is though, there is no references node in my solution explorer. Even if I create a new project, and add a few references, there is no references node there. (MS Visual Studio Express 2013 for Web)
Here is the error:
Parser Error Message: Could not load file or assembly [...] The
system cannot find the file specified.
The error is caused by this line (in my Web.config file):
<add assembly="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
Please help me to either:
display the references node
or manually upload the needed dll (feels odd)
or add some magic command to my Web.config to make it automatically upload the used dll-s.
The references node was missing from my Solution Explorer because I chose to create a Web Site, not a Web Application. For Web Sites, the actual physical folder structure is what gets synced to the server. It doesn't have a References node (and, by the looks of it, many other things are missing, since the basic idea is bit different - see this discussion for more details).
There were two solutions for the problem:
Converting my Web Site project into a Web Application project (instructions here)
Adding a Bin folder in my project folder (that is the folder with the project name, the on that has my .aspx files in it), and including the necessary dll in that folder
I chose the latter. After publishing the site again, Visual Studio automatically uploaded the Bin folder with the dll inside it, and it worked like a charm.
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 have BizTalk orchestration where it reads xml file calls .net class from expression shape and send file to send location but it doesn't work always. It only works like 3 out of 5 times. When it doesn't process my orchestration, I am getting "Could not load file or assembly 'XXXX, Version=1.0.0.3, Culture=neutral, PublicKeyToken=xxxxxx' or one of its dependencies. The system cannot find the file specified."
Please help. Thank you.
On each BizTalk server with a BizTalk host instance, you need to verify that the assembly is in the Global Assembly Cache (GAC). If you can load a Visual Studio or Windows SDK command prompt on each, then run gacutil /l > c:/gac.txt and it will output everything in the GAC to a text file called gac.txt on your C: drive. Look in that file to verify that the assembly (and the right version of that assembly) is deployed on EACH BizTalk server that could be running a BizTalk host instance.
Whenever you make changes to an application, and deploy those changes, I find it helpful to restart the host instance your application is running on.
Also, if you are using an external assembly, perhaps in an orchestration or a map, you need to make sure that assembly is in the GAC (global assembly cache).
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.