This is a lengthy one - please bear..!
I have a web-site that currently uses a monolith "app_code" dll file - and am looking at breaking the dll into pieces for better maintenance.
I'm using the section in web.config to split-up my app_code into multiple, folder-wise dll files. The section looks like this:
<codeSubDirectories>
<add directoryName="CodeSubDir1"/>
<add directoryName="CodeSubDir2"/>
...
</codeSubDirectories>
I've created separate sub-folders for each of the .cs files within the "app_code" folder except for a handful of .cs files that refer each other - so needed to be placed together in the same sub-folder. The .cs files are moved to their corresponding sub-folder.
After these changes, there is no .cs file that is directly under the "app_code" folder. I've set the order of the elements within codeSubDirectories such that all other references are taken care of.
The site builds and publishes successfully in my dev. environment. The "Allow this precompiled site to be updatable" and "Used fixed naming and single page assemblies" check-boxes are checked while publishing. No app_code.dll and app_code.compiled files are created during the publish as there are no .cs files directly under the "app_code" folder. Every sub-folder under app_code is published as app_subcode_sub_folder_name.dll and app_subcode_sub_folder_name.compiled.
Both the site and its published version work fine as well in my dev. environment.
After I update the published files to my staging setup [.NET 3.5/IIS 6/Win 2003], I'm getting these two errors [on two separate URLs]:
Error on URL-1:
Could not load file or assembly 'App_Code, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'App_Code, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Source File: xxx\v2.0.50727\Temporary ASP.NET Files\xxx\xxx\xxx\App_Web_xxx.8.cs Line: 0
Error on URL-2:
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable.
My staging-update process is: I copy the "app_subcode_xxx.dll" and "app_subcode_xxx.compiled" files to the "bin" folder and delete the existing "app_code.dll" and "app_code.compiled" files. I add the codeSubDirectories section to the web.config on staging.
I've searched the GAC, Code and Registry for any reference to the assembly "app_code" with no luck. What am I missing out? Are there any additional steps needed to make this work on my staging site? Do I need to copy ALL other published DLLs as well from dev. to staging?
Copy all the dlls and compiled files from the publish folder to the staging environment. Chances are other dlls and compiled files are still referencing the appcode.
Related
I have a ASP.Net Web Project and used NuGet to include System.Data.SQLite.
That shows under my references but when I publish my app (via "File System") and go to the controller "http://localhost/api/test", it shows the error:
Unable to load DLL 'SQLite.Interop.dll' The specified module could not be found.
I noticed, in my project's bin\Release\net452\win7-x86\x64 the DLL is there, but in the website's actual bin folder, the interop dll is not there!
How do i get it to be included? (I tried adding it as a reference and it wouldn't let me)
Find the location of the interop.dll and add it to the project, then select copy always. This will force the publishing profile to copy it to your deployment.
I have developed a simple .EXE in Visual Studio 2015, which adds an item to the specified SharePoint site and List when the user runs some process.
The file is saved in a shared network drive, and everything seems to work perfectly except for one detail.
I can't seem to work out how to run the EXE without having the following .dll files saved in the same folder:
Microsoft.SharePoint.Client.Runtime.dll
Microsoft.SharePoint.Client.dll
If I move these from the folder in which the EXE is saved in, I get this error message when running the exe:
Unhandled Exception: System.IO.FileNotFoundException: Couldt not load file or assembly 'Microsoft.SharePoint.Client, Version=15.0.0.0, Culture=neutral ... Or one of its dependencies ...
I (think) I have set up 'strong named assembly' by following these instructions in VS for the app, and I was able to add the SharePoint dlls to the GAC by using the VS command line and gacutil.exe (with a successful confirmation message), but I am still unable to run the EXE without having the 2 .dll files present.
Note: I developed the app to target .NET-4, but the users will be accessing the files from a system with .NET-3.5 installed, however the server on which the EXE is saved on does have the .NET-4 environment.
I was able to achieve this by using a tool called ILMerge which can be found here and is available as a NuGet package.
ILMerge allows you to merge dlls and exe files into a single exe
My C# application runs fine (in both Debug and Release mode) when I run it through Visual Studio 2012 or executing the .exe through Debug/Release folder, but it fails when I copy that .exe to some other location and run it. The error message that I receive is:
Could not load file or assembly 'bms.Common, Version=5.0.0.1006, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I am copying the .exe from Debug/Release folder to some folder. Am I doing it wrong?
In Debug folder exists only .exe file? No other dlls? You should copy all .dll files from Debug folder to target directory along with .exe file.
If you want package all libraries into one executable assembly then look at ILMerge utility http://www.microsoft.com/en-us/download/details.aspx?id=17630
usage:
C:\Program Files (x86)\Microsoft\ILMerge>ilmerge C:\my.exe C:\my.dll /out:C:\merged.exe
Generally speaking, you should be deploying the DLLs in the same folder as the executable. With .NET we don't usually compile everything into one big .exe the same way you might link a c program.
There are certain exceptions: for example, you could put the DLLs in the GAC or put them somewhere else and provide what is known as a "probing path." Those are advanced approaches which should not be used unless you know what you're doing.
For complete information on how .NET resolves DLL references, I suggest you read here.
I have written a C# application which uses an external .dll, which is loaded at runtime. The application works fine, if I copy this .dll to the bin directory of my application. Since also other applications use the external .dll I want to have it only once on the system, such that every application uses the same .dll.
So I added the corresponding path to the PATH-Environment variable.
When I delete the .dll from my bin directory and start the application I get a
System.TypeLoadException: Failed to resolve the Type
The way proposed in
Visual Studio: how to set path to dll? does not work
Adding the assembly location to the PATH variable won't make it available to your application because that's not how .NET assembly lookup is performed.
If you want the same assembly to be used by several applications, you'll need to add it to the Global Assembly Cache (GAC). You should note that in order to do that you'll need to sign your assembly. For more information on how to add your assembly to the GAC, you can have a look here.
If it is just your own machine there are a couple of ways if you don't want to use CopyLocal or GAC.
Create a symbolic link to the dll in the bin folder
MKLINK bin\mydll.dll C:\path\to\dlls\mydll.dll
Use the DEVPATH environment variable to specify where assemblies are located
Add the following to the config file (or machine.config if you want a global setting)
<configuration>
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
</configuration>
And then create the environment variable DEVPATH
SET DEVPATH=C:\path\to\dlls;C:\Path\to\somewhereelse
Just ensure DEVPATH contains at least one valid path. Otherwise all .Net programs will crash on startup with a strange error message.
I am writing a DLL which is loaded by a third party application (The FitNesse framework's test runner, the DLL is a test fixture).
The DLL has its own App.config file (say MyDll.dll.config), and I can tell FitNesse to load that App.config file.
But here's the problem: The App.config file contains custom config section handler, like this:
<configuration>
<configSections>
<sectionGroup name="myGroup">
<section name="MySection" type="MyNamespace.MyHandler.MySection, MyNamespace.MyHandler"/>
...
</sectionGroup>
</configSections>
...
</configuration>
Whenever the App.config file is read, the I get an exception saying that the MyNamespace.MyHandler assembly cannot be found, although it sits in the same folder as the MyDll.dll.config file being read:
System.TypeInitializationException:
The type initializer for
'MyNamespace.MyHandler.MySection'
threw an exception. --->
System.Configuration.ConfigurationErrorsException:
An error occurred creating the
configuration section handler for
myGroup/MySection: Could not load file
or assembly 'MyNamespace.MyHandler' or
one of its dependencies. The system
cannot find the file specified
I can see that the system looks for this file in the same folder where the executable that is loading my DLL is located. However, I do not want to copy my files into this third party directory or vice versa.
Is there a way to specify where the system should look for the DLLs to interpret the App.config file? A general solution or a FitNesse-specific solution would both work for me.
Thanks a lot in advance for any help!
You could try using the runtime section as explained here:
http://kbalertz.com/897297/consume-assemblies-located-folder-different-application-folder-Visual-Basic.aspx
Here's another solution we found ourselves. While the solution presented by Gregor S. indeed seems to enable us to read the App.config, we run into other problems regarding the working directory later. So what we are doing now, is adding the FitNesse Runner application as a link to our project, so that it is picked up from its original location and copied to our test application's folder before it is executed.
It's not nice, but it works.