The native PRISM's modulariy mechanism support loading modules by path to assembly, containiтg this module. I want to have availability to store modules' views (XAML) in database in order end user could change and customize them. Database is chosen as it is simpler to store and retrieve information and requires no recompilation and making of binaries.
The problem is that View consists of XAML and codebehind and we need to divide(?) them and store separately and when we need them we must clue them and load to module (with reflection or something else?) but I don't know how and if it is possible at all?
I see two options here. The easy way or the hard way.
The easy way is to have all the assemblies on the drive, and have a PRISM module catalog that loads them depending on settings from a database.
The hard way is to put the assemblies into the database, and have the module catalog load the assemblies from there. You'd have to encode the assembly, probably using Base64, put it into the database, and then reload the assembly from the database.
To reload an assembly from a database record, you can use the same mechanism as the DirectoryModuleCatalog. Copy that class and change it so it loads the assemblies from the stream coming from the DB instead of a file from a directory.
Related
Here's how I usually develop an application:
I start with having all the code in a single source file.
When it grows enough to be modularised, I break the code into several modules.
When the modules grow enough, I split them again. And so on, iteratively.
Over time, some modules get shrunk, deleted or merged with others.
This workflow implies the need to move source files between modules sometimes. And here comes the problem:
When I move a module to another location, it changes the module's name, so I have to walk through all the other files renaming imports by hand.
Is there some organisational technique to avoid that annoying procedure? Or is that the way it goes and I just have to look into some automation utilities instead?
you can create a *.all module that public imports all modules in the package
then you only need to add/remove the module names from that module
You can override module name via module packagename.modulename; directive in the beginning of the module. It will need a help from the build system though as rdmd uses module names from import statements to form file system path to search for their sources. But if you will supply all source files project consists from by hand, it should resolve module names just fine.
It's better to define your entities before you start coding. You can use some modelling language to identify and write your entities. For example if you are using java to code your application then you can use UML to model this application.
Also, you have to separate buisness logic from data.
If you continue to do it like today you will lose a lot of time just dealing with filenames.
I'm following this link, compile razor files into separate dll, and can get it to work except I can't figure out how to access JavaScript, CSS, and Images embedded in the dll.
Has anyone used this approach? It seems very promising. Thanks.
The technique presented in this article is for embedding razor views into separate assemblies. It doesn't allow you to do so with static resources such as images, js and CSS. For those type of resources you will have to implement a custom solution. For example you could write a controller which, given a resource name, could read it from the assembly (GetManifestResourceStream) and write the stream to the response. Then you could simply generate links to this controller action in your views (Url.Action) and pass the resource name.
You can use my EmbeddedResourceVirtualPathProvider which can be installed via Nuget to load all kinds of resources from referenced assemblies, and also can be set to take dependencies on the source files during development so you can update views without needing a recompile.
We have developed a library in C#, and now I wish to create a project template to aid in using the library correctly.
I want new projects to include a reference to the library assembly, but would prefer not to have to deploy the assembly to the GAC, or to depend on the assembly residing in some specific location.
What I am thinking is to include the .dll in the project template .zip file. That means it will end up somewhere inside the project folder of new projects. Perhaps in a folder named Lib. Then the reference hint in the project file can point to that folder. Is that a good idea? What problems might I face down the road?
Is there perhaps some mechanism for including such 3rd party libraries in project templates that I'm not aware of? How have you tackled this? Surely I'm not the first.
I have had to address this issue in the past. In one case, it was a logging library that was installed to the GAC, which meant the Reference element simply needed the assembly name. In another case, we installed the library to the file system, created a registry key that contained the location (in case the user got cute and changed the install location on us) and used a project template wizard to look up the registry key and populate a replacement item to have the correct location in the Reference's HintPath. (Note: the template wizard approach requires you to install your wizard's assembly to the GAC, which it sounds like you're trying to avoid...)
If you don't want your library to be installed in either the GAC or a specific location, the approach of including the assembly in the project is pretty much your only remaining option. On the positive side, deployment of your project template is fairly straightforward and you don't have to muck with the GAC, custom wizards, etc. On the negative side, if you ever create a new revision of your library, your users will need to update every project's copy of the library.
Simple question... I have a VS 2005 solution that encompasses several reporting services projects. Currently, each project has it's own shared data source making changing the database target very tedious.
Is there a way to share the data source across the entire solution (i.e. all the projects in the solution will use the data source defined in one place?).
I thought I could create a project that just held one data source item and then make all of the other projects dependent upon that one, however, the shared date source in the new project does not appear in the other projects for me to select.
Help! I have looked around the web for info, but not much available. There must be a simple solution to this.
Thanks
I am sorry I somehow overlooked your question when I posted the same.
Nonetheless, a technique I am using is described in an answer to it. It feels a little shady and underhanded but seems to be working so far:
Make a new report project to hold your shared data source. I called mine Data Source.
Copy your shared data source (let's pretend it's called My Shared Data Source) to that new project.
If necessary, copy My Shared Data Source to each actual report project and link things up the way you want. But probably you're already set up like this.
Close Visual Studio to make sure all changes are saved in the filesystem and to make sure it doesn't end up clobbering some of our next, "backstage" edits.
In plain old Windows Explorer (or whatever), delete the My Shared Data Source.rds file from every project folder except Data Source's.
Using a text editor or XML-file editor, edit each project's .rptproj file to change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Source\My Shared Data Source.rds.
Now each project still has its own reference to a data source, but all those references happen point to the same underlying physical file, and thus they all share one data source specification.
According to this post by Paul Turley, it appears as if this is not possible. You'll have to copy the data source into each project. The good news is that if you deploy them to the same location, only one data source should exist on the server.
This may not be what you're thinking, but when I'm writing an app consisting of several distinct applicaitons accessing the same data I usually take one of two approaches.
write all of my data access logic into a Class Library project and reference it from the other projects.
Write my data access logic into a Web Service library and add a web reference.
I usually go for option 2 if the data I am accessing is likely to be used in future development, such as accessing company-wide customer lists, etc.
When I debug certain applications (using Visual Studio 2005) I notice strange, randomly named modules are loaded. The names change each time. But they are like di-leyes, jnilel-e, lkmjelxl, llufvuwr. The module path is always identical to the module name. And the module timestamp seems to be the time when the module was loaded.
So it seems that randomly named modules are being created and loaded into the app, which sounds pretty scary.
Has any one seen anything like this? Or can anyone give me some tips on how to figure out what these are?
You need to load the files to see what they do. Mostly they are XML serializers for the types you serialized in your code but forgot to generate corresponding XML serializer assemblies. You probably want to use Visual Studio or SGen to generate XML serializer assemblies because .Net generates one assembly for each type and if you have a lot of types, your memory would be wasted and fragmented by these assemblies and their overheads.