What does it mean by logical grouping of modules in assembly?
Can anyone please explain how .NET's CLR works with assembly ?
You can organise modules using Namespaces. With Namespaces you can make one for each logical grouping of modules within your assembly.
So if you have a Utlity assembly with some string helpers and some file helpers you could put the string helper modules in a Namespace called Utility.StringHelper and the file helper modules in an Namespace called Utility.FileHelper.
A dotNet Assembly is the container for all your executable code. The package that contains the executable code for your program in other words. Your question seems to be confusing a Microsoft term with another term perhaps. Can you clarify your question.
I think you may be confusing an assembly (which is Microsoft.NET terminology for a DLL or EXE file - a binary package of compiled code) with assembly language (the low-level programming languages based on symbolic representations of underlying machine code instructions)
In the context of Microsoft .NET assemblies, logical grouping of modules means organizing your code namespaces according to the role it performs - such as System.Data.SqlClient vs. System.Data.OledbClient - and organized into assemblies (usually .DLL files) so that each assembly forms a cohesive, clearly-defined collection of functions and classes.
For example, all Microsoft's library code for dealing with HTTP, HTML and other Web technology is packaged in the System.Web DLL - and within this DLL there are multiple namespaces so you can selectively including various parts of this technology. This minimises the number of physical DLL files you need to manage, whilst keeping the various responsibilities within those DLLs clearly separated using namespaces.
Related
In my u-sql script I'm using the JsonExtractor that have a reference to "Newtonsoft.Json", in this script I also use a Custom Processor that uses "Newtonsoft.Json" too.
The problem is that the version used in the Processor is different from the version used by the JsonExtractor and it fails when load de dependencies of "Microsoft.Analytics.Samples.Formats.Json.JsonExtractor".
Is there a way to redirect assemblies?
Each U-SQL database can only contain one version of any given assembly. For example, if you need both version 7 and version 8 of the NewtonSoft Json.Net library, you need to register them in two different databases. Furthermore, each script can only refer to one version of a given assembly DLL. In this respect, U-SQL follows the C# assembly management and versioning semantics.
You can find more info here:
https://learn.microsoft.com/en-us/azure/data-lake-analytics/data-lake-analytics-u-sql-programmability-guide#requirements
In your custom processor just declare an alias for your version, and then you can use multiple dependencies by version. Is it possible to reference different version of the same assembly into a single project?
In mvvmcross, I've got a plugin class library which references SQLite for WinRT.
Because of this, I can't build that class library as AnyCPU - instead, I have to reference it as x86, x64 or Any CPU.
This means that new client applications can't just reference a single DLL, but instead individual configurations must reference different input assemblies. Currently I'm doing this by manually editing the .csproj file using conditions.
However, this is a bit error prone (and a bit hard to explain!)
Is there any 'easy' way (1 click way) for client applications to reference the x86/x64/ARM class library trio so that MSBuild then picks the right version at runtime?
If your application does not rely on perfect performance, you might switch to C# SQLite, which is purely managed (Any CPU), so that your class libraries and executable can be set as Any CPU.
Alternatively, you might use Dependency Injection or MEF to inject the assemblies/types of correct bitness at runtime, and in this way at compile time you always work against an interface (which is bitness independent).
As far as I know, MSBuild cannot automatically handle bitness in the way you wanted.
i have to create a dynamically linked library in zOS . What are the options to be passed to the compiler.
Also, how to check if a library in zOS is dynamically linked[dependent] on other libraries.
we have ldd in linux, which shows this linkage. Do we have a 'ldd' equivalent in zOS land?
You don't say it directly, but I assume you mean a C/C++ DLL. You can do shared libraries in other languages as well (even assembler), but the steps would be different.
First, you need to decide what you want to export. A lot of the IBM examples use the compiler EXPORTALL directive, but be aware this can lead to very slow executables, depending on your coding style. If you don't do EXPORTALL, you'll need #pragma export for anything (code or data) you want to export. Don't forget you can export data (variables) as well as executable functions...sometimes you'll need this to share data with DLL functions.
Then, you need to set your compile options on both client (caller) and DLL to use the DLL linkage...this is the -Wc,DLL compile option and when enabled, it generates extra logic in your program to load and manage the DLL. It's a good idea to also include #pragma csect for your exported functions if you think you'll ever have the need to update the DLL without replacing it entirely.
When you link your DLL, be sure to specify the -Wl,DLL option (there are lots of ways...this part is different if you link in batch - I'm assuming you're building in a make file of some sort). The link will generate the actual DLL, as well as a "side deck" containing "IMPORT" statements for all of your exported functions. You'll need these to link any of the client-side programs that you expect to call the DLL. For example, if your imports are in a file called AAA.x, c89 -Wc,DLL myapp.c AAA.x would compile the calling code, with awareness that functions in AAA.x are off in some sort of DLL.
To your point about DLLs calling other DLLs, don't forget that a DLL can both "serve" and "consume" functions...by including the side deck for functions in other DLLs, you can have a DLL that provides some functions while calling other DLLs to access others.
The actual DLL itself can be in several places depending on the nature of your app. If you're UNIX Services friendly, it's just an executable in LIBPATH. It can also be STEPLIB, LNKLST, LPA and so forth.
If you need to, you can access your DLLs explicitly at runtime using dlopen(), dlsym() and so forth. Generally, this lets you control exactly which DLL you're using (sometimes handy if the user can provide one himself), and it gives you what amounts to function pointers that are resolved within the DLL.
There are some other basic things to consider when linking, such as ensuring that your code is reentrant. Most of these are spelled out in the IBM documentation, and if you build with things like "c89" (or equivalent), the correct options are usually setup for you automatically (in fact, to get a good idea of what's going on, turn on the verbose output and see all the parameters for yourself).
If you need to build up a cross reference of what calls what, the UNIX Services "nm" command can give you that information. If you produce detailed link-edit listings, all the data is in there too when you're building your DLLs.
Good luck!
Let's say you have a solution with two website projects, Website A and Website B. Now inside Website A's App_Code folder, there is a Class X defined in a ClassX.cs file. What do you do if Website B also needs access to ClassX.cs?
Is there any way to share this file across App_Code folders? Assume that moving the file to a common library is out of the question.
Please please don't use these unholy website projects. Use Web Application projects instead, pack your shared classes into a library project and reference it from all your Web Applications.
Pack your shared classes into a Library (a DLL) and from each site right-click on add reference and select the library that you have created.
With the restriction of "Assume that moving the file to a common library is out of the question." the only way you could do this is to use NTFS junction points to essentially create a symlink to have the same .cs file in both folders.
This is a terrible option though (for versioning reasons)...moving it to a common library is the best option.
Here's the Wikipedia entry on NTFS junction points
http://en.wikipedia.org/wiki/NTFS_junction_point
and here's a tool for creating them
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
I don't believe that there is a way without moving ClassX into a new code library project. .NET requires all an assembly's dependencies to exist in the same folder as the assembly itself, or in the GAC, to be automatically detected.
You could try loading the assembly manually via the Reflection classes, although it's a bit hacky.
The best solution, if you have the time available and the inclination to undertake it, would be to go with JRoppert's solution of moving it to a web application project. You could then use web references (which work about as nicely as regular references inside VS) to refer to ClassX.
HTH
I have a web application that is becoming rather large. I want to separate it into smaller more logical projects, but the smaller projects are still going to need to access some of the classes in the app_code of the main project. What are some good methods to accomplish this?
Add a class library project with the common classes and add a reference to this project to each of the new projects.
So you'll have the following Solution layout
/webapp1
/default.aspx
/....
/webapp2
/default.aspx
/....
/lib
/Utils.cs
If you are only looking for a way to organize your files, then you can create a folder for each sub-project. This way you'll be able to get to the content of app_code and maintain a level of separation with very little rework.
If you are looking for the best way to do this, then refactoring your code to have a common Class Library based on what is reusable in the app_code folder and multiple, separate projects that reference that library is the way to go.
You may run into problem refactoring the code this way, including not being able to reference profile or user information directly. You are now going from the Web Site to Web Application paradigm.
http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Extract your common code from app_code into a class library which is referenced by each of your other projects.
I like the 3 Tier approach of creating a data access project, a separate business project, then use your existing site code as the presentation layer, all within the same solution file.
You do this, like posters before me said, by creating Class Library projects within your existing solution and moving your App_Code classes to the appropriate layer and then referencing the data access project in the business project, and the business project in the web project.
It will take a bit of time to move it all around and get the bits and pieces reconnected once you move so make sure you set aside plenty of time for testing and refactoring.
In CVS & Subversion, you can setup what I think are referred to as "aliases" (or maybe it's "modules"). Anyway, you can use them to checkout part(s) of your source control tree. For example, you could create an alias called "views" that checks out all your HTML, javascript, and css, but none of your php/java/.NET.
Here's an example of what I'm doing within my projects.
The basic idea is to have all common files separately from htdocs so they are not accessible by client directly and sharable.
Directory structure:
public_html
The only htdocs dir for all projects.
Stores only files which should be directly accessible by client, ie js, css, images, index script
core
Core classes/functions required by application and other scripts. Framework in other words.
application
Stores files used to generate separate pages requested by public_html/index script + classes common to all projects
config
Configuration for all projects, separated by project
templates
Template files separated from all other files
The public_html/index script is then used for all projects on all domains/subdomains and based on the requested URL loads proper pages...
A somewhat simple approach is to group the code in your app_code folder into it's own assembly. The only issue that you could possibly run into is if the code in your app_code folder is not decoupled from the elements on you pages (This is normally always a bad idea since it indicates poor cohesion in you classes).
Once you have your code in a separate assembly you can deploy it to any number of servers when you are upgrading you apps.