Tips and Tricks in a world of Mix

Archive for the ‘Publish’ Category

Setting constant parameter in WebAPI

So the mission was to set static member for connectionString , so that we’ll get the string from web.config just once. On the way we did Encrypt and Decrypt of the connectionString.

So the trouble was that we couldn’t be sure that the static field is staying or going on the request- response model of WebApi.

The easy solution was to reuse the existing code to init HttpContext.Current.Application[“connectionString”] value if it’s null at the global.asax at Application_Start function.

When initialized in that function at the host/server side of the distributed system , the HttpContext.Current.Application[“connectionString”] is initialized for the first time and until the IISReset.

If you want something constant for one request the way to go is to put it in Init function at gobal.asax 

The trouble was that the Application variable has been resetting itself each request.

The solution was that because of decryption that has been saving the web.config it has been resetting the site values held by the IIS, so actually it has been recycling the site data resetting the Application variables values also.

At the end the encryption has been executed on publish to the server, the decrypt has been decrypting the secured section but hasn’t been saving it back , so the web.config actually haven’t changed throughout running host , so the Application data kept intact.

Advertisements

Managing External Dlls–Make Your Project Portable and Independent

   I think that any programmer have tackled with this problem of missing dlls , or suddenly the dlls are upgraded in the server and you are left with your application to pick up the pieces.

  SO , how can we handle the dlls so that our application won’t be effected by almost anything?

  First of all , it is important to understand that the solution presented here does not cancel the need to install the Framework on the destination machine, meaning that the correct framework must be there always in order for your application to work properly.

  There are few solutions for managing your dlls :

1)Reference to GAC as usual

2)Add a folder to specific project with your needed dlls

3)Add a solution folder to your solution and locate your needed dlls there

4)Locate your dlls on some Shared Folder in your organization

5)Build a new Project and insert the dlls there

 

 

In each and every solutions there are Pros and Cons as always :

method pros cons
1)Reference to GAC as usual You don’t need to worry about anything, it’s all in the system. If you are using standard Microsoft dlls , even if there will be an upgrade of the dlls version , Microsoft always tries to make it backward compatible – it won’t touch you. If you have some specific dlls , such as Oracle.DataAccess.dll etc. then it can happen that the dll that you have on your terminal , that you develop with is a different version – in this case when you publish your application on the server your application won’t work properly. You’ll get mistakes of bad assembly reference or one of it dependencies.
2)Add a folder to specific project It’s easy, and whenever you deploy the project you are carrying your dlls with you. If you have a few projects in your solution you can’t use it properly between the projects. You need to keep the location of the folder specific.You could reference the dlls for your current project from a different project folder but when you’ll take the current project as a reference to some third component and then one of the dlls change – you’ll need to recompile all components.
3)Add a solution folder to your solution and locate your needed dlls there It’s a logical unit just holding the dlls – you are adding a logic meaning composing the dlls by logical themes. When you work with TFS or VSS or any source safe you need to have a physical object of a folder. Another thing – if you have a lot of dlls and you need to drag and drop a whole folder of them into solution folder – you CAN’T, so you’ll have to create every folder by hand inside that solution folder and then import dlls files , folder by folder.
4)Locate your dlls on some Shared Folder in your organization That’s one of the “good” solutions if you work in organization with LAN , and ability to control permission over domains . You just throw the dlls to some folder and share it with every one you like. If there are multiple users on the same dll , the system creates copies and you won’t get stacked. The down side is handling the source safe again . It creates decentralization of your application. Another thing , in terms of maintenance  you can always forget the specific location of the shared folder or not get enough permissions after system team will perform some update on the server.
5)Build a new Project and insert the dlls there SO, the great solution yet is to add a new Class Library project , drag and drop the folders you need to take with you and recompile.
Any component in your solution will reference the  autonomic defined component . You can manage it under your source safe and you can enter it in your deployment package – leaving the hierarchy as predefined at the begging. If the dlls change – all you’ll need to do is to throw the External Dlls project to the server.
When you create the project and drag and drop the folders you’ll get “Project file must include the .NET Framework assembly ‘WindowsBase, PresentationCore, PresentationFramework’ in the reference list.”  error . It means that your dlls are defined as a Content . You need to go through the folders , choose the dlls(can choose list of them) and in properties change the Build Action to Resource. That’s it.

 

So , in this review I’ve shown the best way to make your project portable and independent.

Now you can enjoy the deployment. Cheers!

Tag Cloud

%d bloggers like this: