I was going to try Subsonic, you can generate DAL with buildProvider element in an ASP.NET website project. But I get curious why Web applications or windows applications do not support BuildProvider.
PS: I know for Subsonic there is one other option to use it with other than BuildProvider, but I just get curious.
It doesn't work because of the different way things are compiled in web application projects vs. website projects. From what I read on MSDN, it has to do with the fact that in web app projects, all your code files are compiled into a single assembly using MSBuild before deployment, but Build Providers are used to generate code that is compiled at runtime (from your App_Code folder).
In website projects, all of your code is compiled at runtime so it all plays nicely together.
You could possibly hook it into your pre-build event, and call the sonic.exe with the proper command line.
Related
I'm working on a project which is an open-source cloud, similar to Nextcloud. It also provides a file upload and manage feature.
I'd like to have a shell namespace extension which displays those files and folders in the Windows Explorer. Moving, deleting, renaming and editing files / folders should be possible.
Data is available from a REST API or my Electron Client.
I know NodeJS and only some C#.
Is it possible whith NodeJS / Electron to create a shell namespace extension?
If not, are there any free libraries which make this task easier?
Windows Explorer uses 'COM' as its extension model. Therefore, technically speaking, you can use whatever you like, as long as it supports COM.
For NodeJS, you'd be dependent on the runtime to provide the COM support for you and to wrap the appropriate APIs. I'm not aware of any project that does this for the Windows Shell APIs. Here is one for the WinRT APIs.
For C# (.NET), again you'd be dependent on the runtime for COM support. .NET does expose that to you; although it is messy. There are a few projects which wrap the shell APIs and try to hide the COM interop goo as best they can for you.
Here is an open source one.
Here is a commercial one.
Be aware that Microsoft advises against building shell extensions which require a runtime (EG: .NET). The runtime may be loaded into processes that aren't expecting it. Therefore, in practice, Microsoft expects you to use C/C++ to build shell extensions. Here is the Microsoft supplied sample project. It is written in C++.
I am using ODM 8.10 and want to automate building rule app files. The code is currently configured in the old Classic Rule Project, and we are trying to avoid migrating to Decision Services at this time. I have found build jars for Decision Services but nothing so far for Classic Rule Projects. There must be a way to do this as the rule app jar files are created in the eclipse IDE when you deploy/export a ruleApp. I am trying to find out the jar files the IDE uses and the commands it calls to execute the rule app builds.
Re: "There must be a way to do this"
But you will not necessarily have access to it. The ODM product developers have experience, source code, documentation, and other tools that you do not have access to.
Having said that, there is an build/deploy API that you may be able to access via ANT. I haven't used it since switching to Decision Services when that became feasible in ODM 8.7. Standard practice before that time was to automate deployments via Ant and a "headless" version of Eclipse. If the latest online docs don't describe it, you might try the older docs.
WARNING: Classic Rule Projects are a dead end! Not only will all your effort building them in a non-standard way be wasted, I believe that it will likely be more trouble than just migrating to Decision Services (which is not usually that difficult).
In separate Windows 8.1/Windows Phone 8.1 projects, including the SharpDX.targets file from the SharpDX repo includes all of its content build actions in each project. Doing the same in the shared project in a universal app doesn't work (project reloads successfully but tools are no in the Build Action list).
Is there an alternate solution to keeping the content in the shared project rather than keeping copies in each of the W8.1/WP8.1 projects just because there is no centralized way of building it?
No, a shared project in a universal app is never really built. It's merely a container of files to be shared into each of the specific projects. If you have custom build actions, you need to include them in each specific project (that requires them).
What are the correct steps to creating a bindings project for a Framework versus a library? (Yes, they are close to the same thing, but NOT the same, the framework is a directory structure with header files, library and resources). These are what I've come up with, note that none of the Framework specific steps are documented as far as I can tell at the Xamarin web site (please prove me wrong).
Create the bindings project via MonoDevelop wizard.
Generate the ApiDefinition.cs and StructsAndEnums.cs files with btouch or by hand.
Copy the file from the root of the framework directory to lib.a (e.g., ArcGIS to libArcGIS.a) and add it to the project. It is important to note that the file without any file extension in the framework directory is in fact a library file.
?? Include framework resources ??
You'll notice that I get foggy at the third step. How to you add these resources to the bindings project? The large part of the bindings project links and runs fine, but I think it crashes at times because it is missing an expected resource.
You must (a) create a C# contract that describes the Objective-C contracts and how you want your projection into C# to look like, and (b) statically distribute the library with your project.
To kick the automatic population of the linkwith.cs you must rename the framework library (for example MyFramework) to use the library pattern (in this case, "libMyFramework.a")
Resources you have to select and flag as resources, they will be bundled directly into your app, and extracted when the library is consumed.
In my application all images, local HTML pages etc. are marked as "Build action Content".
I have just realized that there is also "Resource".
Which one should I use for images and which one for HTML pages to display in a UIWebView?
Currently I use images like this:
this.oImgLoginLogo.Image = UIImage.FromFile ( "Data/Images/ball.png" );
But in Monotouch.Dialog I see this line:
static UIImage arrow = Util.FromResource (null, "arrow.png");
But arrow.png is also marked as "content"...?
Puzzled.
What are the disdavantages/advantages of each option?
Embedded resources are embedded into the dll or exe file, and accessible from .NET reflection APIs. Content files are bundle resources and are copied into the app bundle (which is simply a directory), and accessible using file APIs or MonoTouch's Apple bundle APIs.
MonoTouch does support embedded resources, but they aren't straightforward to use from Apple-specific APIs, which are designed to use things from the app bundle. However, embedded resources may make more sense when you aren't dealing with MonoTouch-specific APIs, or when you're writing libraries that are portable to other platforms.
MonoTouch 4.0+ does support Content files in dll libraries - behind the scenes they're mangled into embedded resources when the library is compiled, so you can share it as a single dll file, then they're unpacked into the app bundle when the app is compiled.
My guess is that MonoTouch.Dialog was using embedded resources and not bundle resources because it's a library and predates MonoTouch 4, therefore the file marked as Content is a bug in the project.
In the .NET world, the difference is that during the build process a file marked as Content gets copied to the output folder, while a Resource file becomes part of the DLL itself.
AFAIK, MonoTouch doesn't includes resources into the build, because that doesn't exist in iOS, so that's why you always use Content. A final step then zips the directory with the executable and the content files into the .app file, which is how iOS expects it. The same thing is valid for MonoDroid.
The difference between MonoTouch and MonoDroid in the API exist because the idea of those frameworks is to translate, almost one-to-one, the APIs available in those platforms, instead of creating one interface that supports all platforms equally.