I am working on a project which uses an import
#import "progid:Blah.blah.retrieve" rename_namespace("Blah")
but I would really perfer not to register the dll which is I believe what is missing to allow this to work. I don't want to register the dll because our build system will not be able to build multiple instances at a time. Is there some easy way to convert this import into some other form? I have the source for the progid it is importing.
As you can probably tell I don't understand this #import function very well, does anybody know of a good primer on it?
#import brings in the typelib registered against the prog id you've specified. It does this by looking it up in the registry and following the trail it finds there.
You can also just use #import on the dll directly by filename, and avoid the need to have it registered at all. You can even specify the tlb file directly if you have access to it. See the documentation for the #import directive.
If you need more control on specifying the resource that represents the typelib then there is a relevant knowledge base article.
Related
Im trying to run an example project from esp who, it is under single chip examples, cloned from https://github.com/espressif/esp-who.
Its recognition example. Im including a esp_http_client.h but it cant find it.
There is a CMkakeLists.txt and Makefile.
My first question is, do I have to edit the one of those files to include the header, or I have to add the directory path in the gcc.
If so how do I do that.
Thanks a lot.
You need to specify non-default components as a requirement, in your case esp_http_client. Default components are added by IDF automatically, a list can be found here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html?highlight=default%20component#common-component-requirements
If you can, please use cmake. An explanation how to add a component can be found here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html?highlight=default%20component#component-requirements.
Another easy way would be to look at the esp_http_client example. I uses a "common" component for all idf examples which might be enough for starting: https://github.com/espressif/esp-idf/tree/master/examples/protocols/esp_http_client.
Cheers.
I want to make a tcl package , and I am writing In tcl and also in itcl.
Now ,
My first problem is that I have couple of sources files that are included one in the other , so I am adding the command source that should do the include between them. If I create a package with the command package provide is this will still work?
My second problem is that I don't really know how to create this package.
I added to my upper module script the command package provide pack 1.0, but I understood that auto_path should be also updated and mk_index file should with sources in it.
I searched on the internet and couldn't find good example for it.
By the way , I created all my classes and procedures under the global namespace in my sources files , is it ok? or should I wrap them inside a new namespace?
So I searched a little bit more about it and found those two absolutely wonderfull websites:
https://www.tcl.tk/man/tcl8.5/tutorial/Tcl31.html
http://www.wjduquette.com/tcl/namespaces.html
it is explained there very good.
I am attempting to write a reusable package in Go. I'm using a structure similar to that described here but slightly different:
/src/bitbucket.org/EXTERNAL_PROJECT_NAME/EXTERNAL_PACKAGE_NAME/...
/src/INTERNAL_PROJECT_NAME/INTERNAL_PACKAGE_NAME/...
Or should the second line be:
/src/bitbucket.org/INTERNAL_PROJECT_NAME/INTERNAL_PACKAGE_NAME/...
Everything works until I need to access a non-go file that exists in the external package. For example, I have some built in templates that I would like to be available without having to include them in my internal projects templates directory.
To that end, I have a "templates" directory in the external project where I want to house some built-in templates and a "templates" directory in my internal project where custom templates will go. But when I attempt to parse templates from the external project template directory, it can't find them.
So how would I go about indicating that I want to get the templates from the external package directory instead of the internal one? I could adjust the path to something like the following:
../../bitbucket.org/EXTERNAL_PROJECT_NAME/EXTERNAL_PACKAGE_NAME/templates/file.html
but this is obviously very clumsy and depends on individual setup, so that's not going to work. In general, if I want to reference a file in an external package instead of my internal project directory, how would I do this gracefully?
Thanks!
Turns out there is a pretty simple solution. Looks something like the following:
package main
import (
"bitbucket.org/EXTERNAL_PROJECT/EXTERNAL_PACKAGE"
"go/build"
)
func main() {
SrcRoot := "/src"
PackageDir := "/bitbucket.org/EXTERNAL_PROJECT/EXTERNAL_PACKAGE"
InternalTemplateDir := build.Default.GOPATH + SrcRoot + PackageDir + "/templates/"
}
GOROOT here provides us with the path to the directory containing all our go code. From there, I want to reference the templates directory in the package source. With InternalTemplateDir, I now have the base path from which to reference templates within the external package.
For ease of use, I will probably build a template loader that checks for a file on an internal file path first and then checks for the same file in the external package, so that any given template can be overridden by including it internally, but essential templates will all have built in versions as well.
If it's not a Go package (aka bitbucket.org/EXTERNAL_PROJECT_NAME/EXTERNAL_PACKAGE_NAME/file.go) it's not gonna work, your best bet us something like https://github.com/jteeuwen/go-bindata.
But I really think you should rethink your problem and use a different approach to it.
I'm attempting to use Dotfuscator 4.7.1000 to obfuscate a Silverlight library that is strongly named. When I attempt to do so, I get the following error message:
External type not found
System.Data.Services.Client.LoadCompletedEventArgs,System.Data.Services.Client,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
I have tried adding this assembly to the GAC, and have tried adding user defined assembly load paths to the configuration to locations where this assembly is located to no avail.
I then tried adding System.Data.Services.Client to the input assemblies and ran it again. This time it gets further, but ultimately I get:
Warning: Password protected Strong Name files are not supported
sn returned 1.
It appears as though it is attempting to run sn.exe on System.Data.Services.Client.dll with my local key. I've tried excluding this assembly from any obfuscation tasks, but it continues to do so.
Is there something I'm missing when trying to obfuscate this library? Is there some other way to directly point it to the DLL it can't seem to find that I don't know about? Or can I include the DLL in the project without it trying to obfuscate the Silverlight library?
And for the moment, please no suggestions on alternate obfuscators. My company has a license for Dotfuscator and I'd like to get this running using that. Thanks!
Somehow I must have been screwing up my user defined assembly load paths. As soon as I re-added the path to the Silverlight 4.0 client DLLs everything worked without having to reference System.Data.Services.Client.
I'm using Prism 4 with Unity. I have a main project, and a module. The module is created as Silverlight Applications, so it builds a separate xap file.
I load the modules in the Bootstrapper's ConfigureModuleCatalog, just like the documentation states.
var moduleType = typeof (MyModule);
this.ModuleCatalog.AddModule(
new ModuleInfo
{
ModuleName = moduleType.Name,
ModuleType = moduleType.AssemblyQualifiedName,
InitializationMode = InitializationMode.WhenAvailable,
});
Everything works fine, but I notice that my main xap file also contains the dlls associated with my module. So, I set Copy Local = False on the module reference, and it builds correctly with the module dlls only in their own xap file.
But now my app won't run because I can't get the type information for MyModule. I get a FileNotFoundException.
I found that I can drop the reference entirely if I manually enter the ModuleName and ModuleType, and also set Ref = "MyModule.xap" on the ModuleInfo. This works fine, but here's the problem: I build frequently and use dynamic verion numbers. So the AssemblyQualifiedName changes too easily. Without the reference, there's no way to get it dynamically. If I drop the version number from the AssemblyQualifiedName, it doesn't work.
Surely there's some other way to get the module to load from its own xap file without it ending up also in the main xap?
Nevermind...
After researching further, it seems my mistake is in using wildcard versioning in the assembly version. It is suggested on many sites to use the wildcard in the assembly FILE version only, and use fixed version numbers on the assembly version. Then I can just drop the reference and refer to the module by its strong name with fixed version number.
I was so locked in to prism on this one. I didn't figure it out until I thought about assembly location in general. The post that solved it for me actual was about resolving sharepoint parts. Just goes to show sometimes you have to think outside the box.
Update
Looks like you can't use the wildcard in the file version... grr... I found an add-in that will work though http://autobuildversion.codeplex.com/
Anyone got a better idea?