I'm trying to secure a data service used by my Silverlight, and am looking at using a custom SOAP header obfuscated into the SL and HTTPSed.
I've found any number of examples showing how to do this using IClientMessageInspector, IEndpointBehavior, and a few other things. Okay... it all looks straightforward enough.
My problem is though when i try to write my class, and inherit from IClientMessageInspector, it keeps telling me that the interface is not defined. I looked it up in Object Explorer, and it says it's in the System.ServiceModel.Dispatcher namespace. Okay.
I cannot for the life of me get this interface to be "referenced" though. I've added a project reference to System.ServiceModel, and i have the following imports in my code file (all of which are indicated to be okay):
Imports System.ServiceModel
Imports System.ServiceModel.Description
Imports System.ServiceModel.Channels
Imports System.ServiceModel.Dispatcher
Yet when i try to Implement IClientMessageInspector, it still tells me it's undefined, and offers to replace it with IClientMessageFormatter or IClientOperationSelector.
What references/imports do i need to add to get IClientMessageInspector???
Found the problem. The System.ServiceModel.dll referenced in the project is against the runtime v2.0.50727, which does not include the newer interfaces and such, instead of the framework v.3.x version of the dll.
But... now this presents a new problem, which will become it's own question.
Related
I have a legacy Windows project using the legacy 32 Bit C++ compiler. For various reasons I need to use the Windows 8+ function PathCchCanonicalizeEx. C++Builder seems to provide the header and some module definition file for that, but I can't find any library to link against:
[ilink32 Error] Error: Unresolved external 'PathCchCanonicalizeEx' referenced from C:\[...]\WIN32\DEBUG\TMP\FILE.OBJ
How am I supposed to fix this? Do I need to add a Windows 8.1 SDK? Is the necessary lib simply named differently and I can't find it? Something completely different?
According my tests, one has two options:
IMPLIB/MKEXP
I'm developing/testing a some Windows 10 21H2, which provides an implementation for PathCchCanonicalizeEx in some DLL already. So if that source DLL is known, one can use IMPLIB or MKEXP to create an import library manually. I did that and after adding the created library from IMPLIB to my project, the linker errors were instantly gone.
Though, it's not that easy to know where PathCchCanonicalizeEx is placed in. One pretty easily finds the api-ms-win-core-path-l1-1-0.dll, but that thing is NOT an actual file on the disk and therefore can't be used by IMPLIB or MKEXP. That name is only a virtual concept for the library loader to address the same named API set of modern Windows, the extension .dll doesn't mean it's a file at all.
You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names
What you really need to work with is KernelBase.dll, which is even documented by MS.
implib "KernelBase x86.lib" C:\Windows\SysWOW64\KernelBase.dll
implib "KernelBase x86-64.lib" C:\Windows\System32\KernelBase.dll
Module Definition File
The downside of manually creating LIB files is that one needs to maintain those with the project. Things depend on if the target is 32 or 64 Bit, DEBUG or RELEASE, so paths might become a bit complex, one might need to create relative paths for libraries in the project settings using placeholders for the target and stuff like that.
It seems that all of this can be avoided with Module Definition Files, which's purpose is to provide IMPORT and EXPORT statements to either consume exported functions by other DLLs or make that possible for others with own functions. I've successfully resolved my linker problems by simply creating a file named like my app using the extension .def alongside my other project files. That file needs to be added to the project, though.
dbxml.cbproj
dbxml.cbproj.local
dbxml.cpp
dbxml.def
dbxml.res
[...]
The following content made the app use the correct function from the correct DLL. Though, what didn't work was using the API set name, which resulted in an error message by the linker.
IMPORTS
KernelBase.PathCchCanonicalizeEx
IMPORTS
api-ms-win-core-path-l1-1-0.PathCchCanonicalizeEx
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
[ilink32 Error] Fatal: Error processing .DEF file
The latter is after restarting C++Builder, so I guess the format of the file is simply wrong because of the API set name.
Looking for an explanation and education.
I created a class library for a code first database and using the app config created a connection string.
I then added that to a MVC project.
Referencing the class library db context in the MVC project I tried to create a simple record in one of the table and it generated an error.
However, when I put the copied the connection string into the web.config of the MVC project the record was created.
My question is, why do I need a connection string in the MVC project when I am using the db context from the class library which has it's own connection string? It seemed to me that data access would pass through the class library.
I found a similar question: Entity Framework 4.2 code first in a class library ignoring my connection string which seems to imply that as long as I have it in the class library I am ok.
Any insight you can provide on this would be appreciated. Also, let me know what code you need to see and I will provide it. Since I am unsure what you would need to look at initially.
Thank you in advance.
This is by design. All the configurations are read from the config file of the application that is acting as the host. This is because you could be using the same class library in others projects and, in your case, maybe connecting to different databases.
Please, look at this documentation Application Configuration Files :
The name and location of the application configuration file depend on
the application's host
Nowadays, a web project with all the nuget packages and class libraries has a lot of dlls. It would be impossible to maintain if each of one has its own configuration file. I think it's better to be that way.
I have a simple app which uses whirlyglobe framework (2.2). Otherwise, it is pretty basic program with Apple frameworks.
When I tried to validate the app (and during the distribution, Xcode complains that my app is using private API; specifically it calls "rootElement", and "attributeForFont:". I suspect these functions are part of WhilyGlobe component distribution.
What is the easiest way to remove those files from the framework? Do I need to have the source and compile the framework myself? Or is there a simpler way?
Solved. Here is what I did:
1) Searched in github repository of WhirlyGlobe and found the file that uses the functions which caused issue.
2) I did not need the functionality provided by the file that had the functions.
3) Removed the references (class instantiation) to the file from my project.
That's actually part of the KissXML framework and the implementation is in there. I suspect Apple's test is in error.
In any case, if you're not using the WMS functionality, you can probably drop it out just fine.
I have two projects in an F# solution.
1. main project with [EntryPoint] and set as the StarUp project.
2. support, the second project, holds a group of support modules. I.e. they are only called and never initiate anything nor serve as the entry point nor are the StartUp project.
For the last module in the support project, compiling in Visual Studio gives
warning FS0988: Main module of program is empty; nothing will happen
when it is run
While using compiler option nowarn inline as #nowarn "988" in the module causing the warning does suppress the message I would rather add something like a dummy function with comments that resolves the issue.
How does one make such a dummy function to resolve the warning?
EDIT
Jack is correct in that my support project was setup as a Console Application instead of a Class Library. Changing to Class Library resolved the warning. It is also nice to know about do () for the other case.
EDIT
While it seemed odd that I would have set a support project as a Console Application, I recently found that for some reason when I made a change to the code in the project, something changed the Output type from Class Library to Console Application. I suspect it has to do with the F# PowerPack and it's build rules, but it's only a guess.
Are you building the support project as a Library or as a Console Application? (This is set via the project properties page.)
If you're building it as a library, then you may need to add a do() at the end of the last file in the project. This is necessary to make the F# compiler happy in a few specific scenarios, like when you create a module which contains only assembly-level attributes (because they're applied to the assembly, the module appears "empty" to the compiler).
You can see an example in my code here:
https://github.com/jack-pappas/FSharp.Compatibility/blob/master/FSharp.Compatibility.OCaml/AssemblyInfo.fs
I have written a few razor helpers and these helpers use functions that include the extension methods generated by T4MVC.
I now want to move these to a control library so that they can be used across multiple mvc applications.
The initial idea that I have used is that I can put a copy of the template into the control library, and this works, the downside is that the template used in the application then regenerates the same extension methods in the same namespace.
Because I am using some of the extension that require the interface for the ActionResult I do need that the namespace remains the same.
What I am wondering is, is there a known way to use the extensions in a control library as well as an application that references the library, or is a change to the template required such that the static extension methods can be either generated or not via a flag in the settings file?
I am also wondering if the static extensions could be included in a separate cs file that lives along side the template. So that we have 2 classes T4Extensions and DynamicT4Extensions?
This might force the use of the interface IT4MVCActionResult though,
This is similar but not quite the same as http://forums.asp.net/p/1510753/3603100.aspx.
I wonder if the solution might be to add a new switch in the settings file that would turn off the generation of those static methods. So if you know you're already getting them from some referenced assembly, you'd turn them off in the app.
Though that might still blow up if you have multiple unrelated libraries that each need to use the methods, as the app would then get an ambiguous reference.
Note that we can't make the methods internal, since some of them need to be called from views, which live in different assemblies.
And ideally, I'd prefer to avoid having those in yet a separate file, as some users may start complaining that T4MVC brings in too many files.
Sorry, not really a clear answer, but more thinking through possibilities. :)