I have built a plugin that has a number of dll's. When running this with Petrel 2012.5 it works fine with no issues. However after using ILMerge on the same dll's and then running in Petrel with the merged dll I now get InvalidOperationException's (Workspace not yet opened). Has anybody else had this issue?
Related
I have two problems with DLL compiled with VS2015 XP toolset when called from non VS2015 exe.
First and most serious is that using in such DLL-s tls variables (like statics declared inside function results in GPE on XP/Server 2003R2). Works fine on Windows 7+ and/or when called from VS2015 exe. Looks like something in runtime isn't initialized when called that way.
The second problem is with side by side installation of W10SDK/runtime DLL. Everything works fine with EXE but doesn't load from DLL path. You have either to install runtime or to copy DLLs to exe directory.
Can anyone suggest a solution especially to the first problem (second is annoying but can be handled).
Found a duplicate for first problem with workaround
Crash in CAtlStringMgr::GetInstance under Windows XP
What concerns second one - solved it with writing a VS2012 DLL proxy that chdirs to proxy directory, loads the library and then chdirs back (and then calls through all calls to VS2015 DLL. But would be glad to find more elegant solution
we are using NSASS to compile our Sass files to css ( https://github.com/TBAPI-0KA/NSass ). NSASS is set up and working great in development environment. But when we try to deploy it to our testserver we are unable to get NSASS up and running.
We keep getting
Exception information:
Exception type: FileNotFoundException
Exception message: Could not load file or assembly 'NSass.Wrapper.x64.dll' or one of its dependencies. The specified module could not be found.
at NSass.SassCompiler..ctor()
at NSass.SassHandler..ctor()
The problem is that NSASS uses some dynamic way to load these dlls, that does not seem to work. The dll is located in \bin\NSass.Wrapper but fuslogvw is logging that it only tries to search the bin directory. The dynamic way of loading this dll is made so that it loads the x86 or x64 depending on the OS if I understand correctly.
For the bin loading code of NSASS: https://github.com/TBAPI-0KA/NSass/blob/master/NSass.Core/AssemblyResolver.cs
I have tried moving the dll files (both X64 and x86) to bin folder but I get the same error looking in event viewer even if the fuslogvw says that all is ok.
Anyone have any tips on what I can do as a next step to try and solve this?
Edit:
Tried logging AppDomain.CurrentDomain.SetupInformation.PrivateBinPath and it points to the bin folder as it should and AppDomain.CurrentDomain.BaseDirectory points to the correct folder aswell. Not sure if anything change the CurrentDomain from Application_Start where I log until the Assembly Load of the NSASS files.
Also worth noting. This is an EPiServer web so not sure if EPiServer changes anything. But if so shouln't it be problems in the Dev environment as well?
I finally found the issue!
After using DependencyWalker to analyze the dlls of NSASS I found that the server did not have the correct version of C++ Redistriburable.
So after installing that all works fine!
Hope this helps other people with the same issue.
We had the same issue but the fix ended up being two things.
Installing Visual C++ Redistributable Packages for Visual Studio 2013 onto our servers.
can be downloaded here
Changing our compiler to libsass-net using nuget, it seems very similar to NSass (github).
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
I have a native DLL (x64) built with VC++ 2008 that I'm trying to use in an azure project. The code runs fine in a standalone executable, but when I try to run it in the Compute Emulator, I receive a DLL not found exception.
For several days I've been assuming the issue is with the VC++ redistributables not being present, but that shouldn't be an issue with dll's built using VS 2008.
Using ProcMon, I discovered something odd -- the DLL is not being found anywhere on the path. Further poking around showed that the DLL is not being copied to the approot folder, despite the fact that it is set to Build Action = none + Copy Always.
I manually copied the DLL to the Compute Emulator's path in the SDK and now it runs. But why does VS not copy the DLL along with my project files into the approot when I press F5?
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.