My ASP.NET application uses only 1 SQL Server 2000 database and no more than 50 tables in it. And I copied an instance of the database to run on my develop PC, so I need to switch the connections between dev and release.
The problem is, I had created multiple class libraries in my business layer, and each class library has a LINQ to SQL class. Now I find it difficult to make all of the DBML files in the different projects use the same connection string.
So is my design wrong? Should I only use 1 class library? If I continue to use multiple class libraries, how do I ensure the same connection string is used in all libraries in release mode?
Put your DBML in its own class library (assembly), and reference it in your other class libraries. That way, you can make your changes to the DBML in one place.
If you have partial classes that implement business logic, I would go ahead and put those in your other class libraries.
Related
I follow the best F# practices from .Net documentation:
I create a project for the Application (console, not library)
I create a project for the Tests (with Expecto but doesn't matter)
Problem: Some of my Application modules are not exposed via the internal keyword. Thus I cannot import these modules in my Tests project.
=> How can I perform unit testing of these modules? Should I remove the internal access control?
Thanks!
To test internal, you can use InternalsVisibleTo, to test private classes, you can link the files in your test project (when you are in the "add file" dialog, you can select link, instead of open).
However, as already has been commented, generally you would only test the public interface. But occasionally you want to separately test complex internals as well. For instance in the .NET runtime libraries, this is often done (there are a lot of complex internals), and they use the linking approach a lot.
Since private really means private to the class, and you won't even be able to access such members from an extension method, you should put such members in their own private class, as public members. That way, when you link, the class is accessible, and the members as well, but neither are accessible in your production version.
Use this technique sparingly, because it will bind your private details to the test system, and you won't be as free to change the internal implementation.
I am novices to the field of Identity and Access management.
Till now I know, Sail point has provided the some direct connectors to integrate the known systems like LDAP, HR systems, OIM, Databases..
And sailpoint also provided the support for disconnected applications with the use of Custom connectors.
Here, My question is how to develop a custom connector..?
I do not have jar file provided by sailpoint which contain "AbstractConnector" class.
So that I can write my own class and develop..?
I also so not understand, what to do with that class?(if i have a jar)
How sailpoint will refer to that class..
Do we need to deploy that class to somewhere...
Here I am expecting the complete flow to develop and deploy the custom connector..
If anyone is working please help..
If you unzip your identityiq.war, you'll find a JAR file called WEB-INF/lib/connector-bundle.jar. This is the JAR where you'll find AbstractConnector. Once you've written your connector code, you will need to compile it and bundle it into a JAR file, which you will place into WEB-INF/lib.
Finally, you will need to update the ConnectorRegistry object (under Configuration on the debug screen) to reference the new class, which will make it available as an Application type. If it has custom connection parameters (as most do), you will also need an xhtml page that will be embedded into the Sailpoint UI to prompt the user configuring the Application.
If you have Compass access, they have a whitepaper called Custom Connectors that you will find helpful.
All that said, I encourage you to try to find a way to use an out-of-box connector if possible.
Most of the times it will be better if you use the DelimitedFile connector, you can import a CSV of identity data, and make it work within Sailpoint's workflow. You will be able to map fields, correlate accounts and create multi-valued group memberships rapidly. Of course, this means that Sailpoint will not be connected directly to the application, and you will have to develop a workflow to extract the identities and upload them. But at least, you can integrate without going the Custom Connector way.
I have one project with multiple libraries. The problem I have is that I can’t access some libraries from others, as when I add a reference I get an error about circular dependencies. I assume I need to create an interface but I am not really sure how to structure it. Here is an example of what I have:
My references are setup like this:
WebApp (This is an ASP.Net web site) - Has Reference to BusinessLayer Class Library and Utilities Class Library
Data Class Library (This library provides abstract database functionality) - has no references
BusinessLayer Class Library (provides a business logic layer) - has references to Data Class Library, DataLayer Class Library, and Utilities Class Library
DataLayer Class Library (provides a layer that directly interfaces with the database i.e. CRUD commands) - has references Data Class Library and Utilities Class Library
Utilities Class Library (general library that are used across all layers) - has no references
For the most part this is fine. But, I have a class in the Utilities Class Library that needs to reference functions and properties in the WebApp and BusinessLayer Class Libraries. I cannot add a reference to these projects, as that would create a circular dependency. So, how would I go about setting up the Interface and the correct references?
The way you have designed your application is very similar to architecture pattern defined
here
As for your utility class, you can define an interface in BusinessLayer/domain layer and implement that interface in utility layer. Please note it should only return types defined in business layer/domain. This way you will get a nice separation of concerns. If let's say your web needs to consume this utility method, you can apply transformation to convert your domain type into web project specific type. This way you won't run into circular dependency.
I created a sample application based on these principles, you can refer to my github
project.
It sounds like you need to move those common functions out of webapp and into your utilities library. I don't think you should be referencing your web app from any of your other libraries.
LINQ to SQL Connection Strings with class library projects
By default, creating a new LINQ to SQL model (.dbml) will put the
connection strings in both the application settings file and also
web.config / app.config. This is not so much of a problem for web
projects, but what about class library projects? i have a connection
class where I can use it to check connection in all pages but I have an
error where it cant read DataContext at all.
This is a photo that shows my problem.
Generally speaking, class libraries don't support config files. There are ways to make it work, but it's not considered a good practice since different applications may use the same library to interact with different instances of the database. I would recommend looking at a dependency injection or inversion of control solution like Ninject to pass the connection string to the constructor from the app that references the library.
UPDATE:
If you absolutely must read a config file from an assembly instead of the calling application, it can be done with ConfigurationManager.OpenExeConfiguration(). There are several answers here on SO that provide code samples for doing so, but I'm not going to link to them because I strongly encourage you not to go down that road.
By the looks of it you're not using LINQ to SQL - all I can see is an EntityFramework edmx. Check your code generation strategy, and make sure you're trying to instantiate the correct context name (think it's whatever the Entity Container Name is set to).
Also you need to make sure System.Configuration is referenced.
You need to put the connection strings in the main application app.config
Just put a copy of the connection strings in there and you can access them or in this case web.config
I understand C# Code Fragments and .NET Assemblies offer the same functionality for modular template development. We manage the code fragments in the CME and assembly code in Visual Studio, but use both the same way in Template Builder.
In terms of code, I can create a C# Code Fragment Template Building Block (TBB), for example:
var timeStamp = DateTime.Now.ToString("d MMM yyyy");
package.PushItem("timeStamp from fragment", package.CreateHtmlItem(timeStamp));
I can also create a .NET assembly Template Building Block using the same code by implementing ITemplate as below.
using System;
using Tridion.ContentManager.Templating;
using Tridion.ContentManager.Templating.Assembly;
namespace CreateAndBreakTemplates
{
[TcmTemplateTitle("Add Date to Package")]
public class AddDateToPackage : ITemplate
{
public void Transform(Engine engine, Package package)
{
var timeStamp = DateTime.Now.ToString("d MMM yyyy");
package.PushItem("timeStamp from assembly",
package.CreateHtmlItem(timeStamp));
}
}
}
The docs explain that "SDL Tridion inserts the code fragment in its predefined method of a predefined class." It looks like this class implements ITemplate and adds some references below (am I missing anything?).
The assembly setup instructions mention at least these dlls.
Tridion.Common.dll
Tridion.ContentManager.dll
Tridion.ContentManager.Templating.dll
Tridion.ContentManager.Publishing.dll
Any other difference between fragment and assembly and how would you choose between the two?
A C# fragment is compiled into an assembly by Tridion when the template is first invoked and after it's been modified. To compile the fragment, Tridion wraps it in some "dungeon dressing" (bonus points for those who know where that term comes from) that:
Uses the Tridion.ContentManager, Tridion.ContentManager.CommunicationManagement, Tridion.ContentManager.ContentManagement and Tridion.ContentManager.Templating namespaces
Makes the Package and Engine available in fields called package and engine respectively
Creates a logger for the C# fragment that is available through a field called log
Adds references to some commonly used assemblies (but does not add a using for their namespaces yet)
Edit: given the other answers it seems many people are not aware of how to accomplish certain tasks in C# fragment TBBs, so I'll document them below:
Import additional namespaces
To import/use additional namespaces into your C# fragment, you need to use this syntax:
<%# Import Namespace="Tridion.ContentManager.ContentManagement.Fields" %>
Note that this will only import namespaces from assemblies that are already referenced by Tridion. There is no mechanism for you to add references to other assemblies explicitly; so if you need a third-party DLL, you will need to add it to the GAC.
Defining custom functions
You can define custom fields and functions in your C# fragment by using this syntax:
<%!
public static string GetDate()
{
return new DateTime().ToString("u").Replace(" ", "T");
}
%>
Defining member fields and (nested) classes
The syntax for defining custom functions also allows you to define nested classes and/or member fields:
<%!
public class MyLittleHelper
{
public MyLittleHelper(string param1)
{
}
}
%>
Frank has explained the difference between the two approaches, but that still leaves the question of how to choose between the two. My personal advise is to never use C# fragments for anything, with only one exception*. As you have found out, there is some dark magic going on in them that I personally do not like. Also, there is so much you cannot do in them that a .NET programmer is quite fond of, such as creating classes.
Putting my personal taste aside, I see only one reason why you would ever resort to C# fragments: if you do not have access to Visual Studio or another tool that builds DLLs. And that is not a very strong argument either: if you want a job done, you should get the proper tools!
*The exception being the C# fragments that Tridion automatically creates for each ITemplate in your assembly, of course.
The main differences between C# code Fragment and .net Assemblies in my point of view are categorized into below high level buckets.
Step-by-Step Debugging
With .net assemblies you could do step-by-step debugging from visual studio where as C# Code fragments it is not possible.
Re-Use or Base Classes
With .net assemblies you could extend ITemplate to create something like BaseTemplate and all your template could extend them so you have common design pattern, where as C# there is no concept of BaseTemplate other than Tridion ITemplate interface.
With .net assemblies you could add common utility classes (often TridionUtilities) and all your templates refer to the same TridionUtilities for common functionality. C# code fragment the utility functions need to be defined within the same TBB and cannot be reused with other TBBs unless you create a class and deploy to GAC.
Easier Upgrade Scans and Maintenance
With .net assemblies it is easier to do any upgrade scans like deprecated APIs/Methods simply referring to new dlls/.net framework. .net assemblies make it easy to identify potential impacts on planning either Tridion upgrades or .net framework upgrades. C# code fragments it is much harder to find the deprecated or any impacts of upgrade.
Developer Friendly
Obviously .net assemblies are developed using Visual Studio (developers love it!) vs. C# Code Fragments in a Text Editor (painful).
When I started back with Tridion 5.3, started with C# code fragments and quickly realized what a mistake I made for not going .net assemblies.
My vote is always .net assemblies and C# code fragments is not even in consideration unless I don't have a choice. lol..
I think the differences indeed are best explained by Frank's answer, as to how would you choose between the two. I normally say, since you are using Visual Studio anyways, always create a .NET Assembly TBB for your code. They offer you a lot more benefits like including 3rd party assemblies, allow for proper coding with classes and methods a lot easier and probably most important, allow for proper debugging (although this last one can be hard to setup depending on where you are, thinking of customer environments, firewalls etc.).
There are for me only two exceptions for using C# Fragments:
The references to classes implementing ITemplate in an assembly, allowing you to use these as separate TBBs
If there is a requirement to manage constants or other hardcoded constants directly from SDL Tridion
Number 2 is of course debatable, but you never can do without configuration properties, for a TBB most of these you can handle using a Parameters Schema, but sometimes it is just a lot easier, to directly write them in a C# Fragment and have that push them to the package for other TBBs to use.
In my training sessions, I usually referred to the following story of the only time I ever choose to use a C# Fragment TBB so far, indicating how much of an exception it is to use them:
I was working at a customer abroad, and my taxi for the airport was leaving in 10 minutes when one of the developers I was coaching asked me a question on how to get a list of items from a Folder in his TBB. I had already closed my Visual Studio and Outlook and was about to shutdown my laptop, but quickly browsed through some of my code samples to find what he needed. Knowing that starting up Visual Studio or Outlook would take a few minutes, I quickly pasted the code in a C# Fragment so he had it for easy reference.
I would never use C# fragments for the sole reason that it makes management of your code quite difficult and you need to manually deploy them. And if you do write your code from Visual Studio, then you should create a .NET Building Block assembly.