We have recently added AppFabric as a caching option in our project (Windows server version, not Azure cloud). The project thus now has a dependancy on Microsoft.ApplicationServer.Caching.Client.dll and .Core.dll.
Our build server is Windows 2003 and thus AppFabric cache cannot be installed onto it, thus these assemblies are not available.
Short of including the afore mentioned assemblies as explicit binaries in our SVN repository, and referencing them directly (yuck), are there any suggestions as to how to build the project?
Secondly, if we checked in the binaries, performed the build then deleted them from the output folder, is there a way to force .NET to search the %windir%\system32\AppFabric\ folder for the assemblies?
MS do not register them in the GAC...
If your application is using an assembly that can't be installed on your build server, then the solution is to upgrade your build server to Windows 2008.
Related
Setup:
single offline (blocked from inet) server
multiple applications
apps load .net core assemblies (plugins with their own assembly or nuget deps) at runtime through reflection
Problem: What is the most efficient way to deploy the application set?
Currently I publish application per application, so that all required nuget packages and assemblies are available. However, this means the complete .net core and asp.net assembly set is copied over multiple times.
To have a shared deployment with an installed .net core runtime or sdk, there does not seem to be an easy way to make the required nuget packages available on an offline machine?
Any suggestions on the best-practices setup for these kind of deployments?
Cheers.
Sounds like you could use the global packages folder.
If your projects use PackageReference they consume their dependencies directly out of that folder instead of copying them locally, so if you're worried about disk space that would be a way to avoid duplication if that's what you're really worried about.
Package is installed on local machines with a reference to packages folder added in project. Now If I publish it on server, it is causing problem as glimpse is not installed on server. Please guide what is the best way to install it on server.
Glimpse just needs its DLL's to be in the bin folder on the server.
Some deployment techniques (like on Azure Websites) leverage NuGet package restore to download dependencies and build your site right on the server. With these techniques you don't have to do anything.
For simpler techniques, like xcopy or FTP of files, just make sure to include the DLL's - they are already being copied to the bin when you build your site.
I am trying to set up .Net builds on our Hudson (CI build) server. One application uses Microsoft.Office.Interop.Excel.dll. This is not found on the build server and causes the build to fail.
I obviously don't want to install Office on the server just for this case so what do I do?
To clarify: this is a build server. The project is not run on the server and Excel is not needed except to satisfy the compiler.
Install the primary interop assemblies:
Office 2003: http://www.microsoft.com/en-us/download/details.aspx?id=20923
Office 2007: http://www.microsoft.com/en-us/download/details.aspx?id=18346
Office 2010: http://www.microsoft.com/en-us/download/details.aspx?id=3508
Those PIA's should be also deployed to the GAC when you install Visual Studio (if you can).
You might also take a look at this question: Unit test with Microsoft.Office.Interop dll fails on build server
This is straight forward if you are using nuget and any repositories like nexus for dependency management. In our project we use VS2017 which has msbuild nicely integrated with nuget and it does the job to download this dll locally and on build server.
Hope this helps
This is Edited from the OP. This is a VB .NET 4.0 WinForms application. There is a mysql datasource involved with this project. The target CPU is set to any. Problem: When running this application on any computer that has VS 2010 installed along with the mysql connector it runs flawlessly. When installing on a virgin system(ie. No developer environment installed) but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately. So to fix the issue I install the mysql connector MSI. This immediately fixes the issue on the client system and it runs. The problems is that as you can see below from my Installer setup that the 2 needed DLL files for MYSQL are actually included in the installation package so should not need to be installed separately. So Why is it that using that installer from the images do I need to install the mysql connector? Any Ideas? Below is a screen shot of the References the program uses and from what I believe I do not need to deploy any of those DLL files with my application other than the 2 MYSQL DLL files. So why is this failing?? Below are images showing the project references as well as the Installer Files that are being installed in the applicaiton folder. As shown in the image the 2 mysql dll files are to be put in the application folder. There is also a screen shot showing each dll's properties for in application folder.
You answered your own question.
but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately.
You don't need to install the connector msi package, but you do need to include the two DLL files in the application's directory. Anytime you have some dependency, you need to deploy it with your application.
Edit solution quoted from my comment:
From your update it sounds like you have a version mismatch on the
assemblies, and the references are set to Specific Version = True.
Check the version number of the assemblies on your developer machine
in the output directory, and check the version you are installing on
the client system. (You can just hover over the DLL to read the
version on the ToolTip). You can try to set Specific Version to false
by right clicking your reference and selecting properties, or simply
ensure you deploy the same version of assemblies. Your program is
looking for the versions its compiled against
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.