I've got an Ektron 8.2 site, and I was trying to integrate Quartz.NET into it, in order to run some scheduling. Quartz.NET requires a library Common.Logging. This library introduces a conflict and breaks the Ektron code in App_Code/VBCode.
E.g. the following code from Utilities.vb
Case Is = Common.EkEnumeration.FolderType.Community
imageURL &= "images/ui/icons/folderCommunity.png"
Case Common.EkEnumeration.FolderType.Catalog
imageURL &= "images/ui/icons/folderGreen.png"
now gives a compile time error-
App_Code\VBCode\Utilities.vb(703,0): error BC30456: 'EkEnumeration' is not a member of 'Common'.
It appears that Common.Logging is conflicting with Ektron.Cms.Common (the Ektron files have a Imports Ektron.Cms statement). Is it possible to specify the priority on libraries? Or namespace an imported library?
Update
The Utilities.vb code is written by Ektron. I'd like to either make no changes to this code, or minimal changes, as any changes would need to be re-done upon Ektron upgrades. This is really a clash between 2 libraries - Ektron and Quartz.Net. Can I resolve this clash without changing the code of either library? Is there a configuration setting for aliasing libraries?
A simple solution is to use the full namespace, Ektron.Cms.Common.EkEnumeration, rather than relying on the include to sort things out automatically.
I.e.
Case Is = Ektron.Cms.Common.EkEnumeration...
Not elegant, but should get you working again.
Another alternative is to use a namespace alias:
using EkCommon = Ektron.Cms.Common;
So your code would instead look like:
EkCommon.EkEnumeration.FolderType.Community
Related
I'm trying to implement my template matching (with drawing) in AOT form and when I was testing whether the different methods work by including separate static libraries that are compiled from another project, I got build errors like:
Severity Code Description Project File Line Suppression State
Error LNK2005 _ZN6Halide7Runtime8Internal13custom_mallocE already defined in template_matching_ccorr.lib(template_matching_ccorr.lib.obj) Halide Template Matching v2 AOT Run c:\Users\Admin\documents\visual studio 2015\Projects\Halide Template Matchign v2 AOT Run\Halide Template Matchign v2 AOT Run\template_matching_sqdiff.lib(template_matching_sqdiff.lib.obj) 1
Is there a way to be able to include multiple libraries and be able to run different functions?
Also is there a similar function as realize that can be used in a AOT compilation code or would that require me to make two different AOT functions (assuming I can call multiple functions to begin with)
EDIT: a quick fix seems to be adding /FORCE:MULTIPLE to linker's command line
EDIT2: managed to get it to compile with adding
Target target = get_host_target();
target.set_feature(Target::NoRuntime, true);
to most of the pipelines except one which solves the multiple definitions. Now I'm wondering why I have to have one pipeline with the runtime even though I could just include HalideRuntime.h but it doesn't really work.
/FORCE:MULTIPLE works. So does judicious use of the no_runtime target feature. See http://halide-lang.org/tutorials/tutorial_lesson_15_generators_usage.html for details.
You can compile each pipeline without a runtime, and then link them together with a standalone runtime. Or you can just compile one of your pipelines with a runtime.
Is there a way to get all function used in code.
Actualy I have a big dll which provides me an api of third-party system and now I need list of functions from this dll I'm using.
Is it possible? What way is better: macro or vs extension?
I guess, the API has a separate namespace. Unless you use explicit calls like: Third.party.namespace.ClassName.Method() you can remove using clauses and then filter somehow the errors the compiler shows you while rebuilding.
Or you can start by removing the references to the 3rd party assemblies, which will generate errors for all usings. Then you remove the using and then see every bit of code that relies on them. As I said unless there are explicit calls (which means there were some ambiguities) this should work.
I've been rather confused by some SGEN stuff. I've enable the generation of serialization assemblies for one of my projects. Originally I got the follow error which I believe I've solved by doing some caspol stuff on a remote assembly.
Unable to load one or more of the request types. Retrieve the
LoaderExceptions propery for more information
Now however, I don't get an assembly generated. Adding some debugging/verbose output provides the message "SS.dll does not contain any types that can be serialized using XmlSerializer". I've read that this is because of a proxy switch applied by VS. The odd thing is it doesn't seem to be a problem with any other project.
So if I disable the proxy switch (example here) it seems to work. The linked build events however seem to do all projects. I don't know enough about MSBuild to tweak to just a single project, does anyone know what I need to change?
Additionally, if this change is made, is there a way I can automatically include this in a installer (VDProj)? I can't statically link to the SS.XmlSerializers.dll because the each dev uses a custom path.
Discovered the following post which talks about adding the <SGenUseProxyTypes>Off</SGenUseProxyTypes> to the csproj file which seems to work :)
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.
I have a project compiled using __cdecl calling convention (msvc2010) and I compiled boost using the same compiler using the default settings.
The project linked with boost but I at runtime I got an assert message like this:
File: ...\boost\boost\program_options\detail\parsers.hpp
Line: 79
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
There are the following questions:
what calling convention does boost build with by default on Windows (msvc2010)
how to I compile boost with __cdecl calling convention
why boost wasn't able to prevent linking with code with different calling conventions? I understood that boost has really smart library auto-inclusion code.
Update #1
It looks that boost does compile and link with proper calling convention, still at runtime I get the above problem. I did a sample application using the same code and it works but in my application it fails. The only difference could be from project configuration or includes/stdafx.h
Just use
bjam ... **cxxflags=/Zp4**
while building boost libraries.
As far as I know there's not way to make C++ use cdecl calling conventions (see MSDN Calling Convention). The C++ method calling is just different from C. The only opportunity that you have to use one of the C calling conventions is for functions, which include class static functions in C++. If you know that's the case you can try forcing the option when building by adding the option during the build:
bjam cxxflags=/Gd ...
(see BBv2 Builtin features)
Or to make it "permanent" set up a user-config.jam with your compiler and add it to the build options for all BBv2 msvc builds (see BBv2 Configuration and related docs). As for you other questions:
Boost uses the default calling convention MSVC uses, except for cases where it overrides it at the code level. I don't know where those are as they are library specific. So you'd have to search the code for the "__*" code decorators.
See above for partial answer.
Detection; there are two reasons: There is a limit to how many different options we can reasonably detect for for building as it's an exponential growth of different possible variations so we limit it to the most important cases. And in the case of calling convention, it's not actually possible since it's something that can be changed on a per function basis.
I found the cause of the problem inside one of the shared property files: <StructMemberAlignment>4Bytes</StructMemberAlignment>
If I remove it the code will work. Still, I'm not sure why this is happening and how could I solve it without removing the above code (that was required by another library).
I added another question regarding boost and structure member alignment.