Zip File .Net Framework 1.1 - zip

How Can We Zip A File In .Net Framework 1.1 Without Use Any Third Party Control...

By coding everything yourself.
Or, if the MS J# runtime doesn't count as 3rd-party, you could also use that.

Using just the .NET Framework, you can't. This will be something that will be provided in some later version of .NET (not yet released from what I could tell). However, due to J# being part of the .NET Framework, you can essentially use Java do Zip and Unzip files for you. The details are described at this site: Zip and Unzip Files in C# using J# Libraries

Related

WindowsAzure.Storage SDK missing APIs in .NET Standard

I am converting a .NET Framework 4.7.1 class library to .NET Standard 2.0.
The library consumes a number of Nuget packages, all of which are available for both .NET Framework and .NET Standard and these packages include the WindowsAzure.Storage SDK.
The original .NET Framework class library compiles and runs correctly, but the .NET Standard library fails to compile, due to missing APIs (and some different method signatures) on the WindowsAzure.Storage SDK.
For example, CloudBlockBlob has a DeleteIfExists method in .NET Framework but not in .NET Standard.
The API documentation lists this method (and all the others that are broken in .NET Standard) but doesn't appear to mention any version differences between target frameworks. Did I miss something relevant here?
Is it normal that some .NET Standard Nuget packages have gaps in their APIs?
Is there a solution or a workaround for this (apart from re-writing the code that consumes these APIs)?
Thanks, in advance.
As per Peter Bons mentioned, In the nuget package WindowsAzure.Storage, there are only task based methods, so DeleteIfExistsAsync for .net core / .net standard.
Please use the new nuget package for azure storage. For blob storage, you can install Microsoft.Azure.Storage.Blob, version 9.4.0 or above, which does support sync / async methods.
The change log is here:
And here is a simple test with .net standard project with Microsoft.Azure.Storage.Blob, version 9.4.0 or above installed. Both sync / async methods are there.

Target .NET Core 2.0 with Azure Functions in Visual Studio 2017

Since Microsoft has released .NET Core 2.0 for Azure Functions a few days ago, I'm trying to understand how to create a new Functions project in VS2017 targeting .NET Core.
I've tried many configurations and still ended up with .NET 4.7.
Did anyone manage to create a new Function targeting .NET Core?
Thanks.
This is supported with the 1.0.5 release of the Microsoft.NET.Sdk.Functions package.
In your Azure Functions Project, do the following:
Update the Microsoft.NET.Sdk.Functions package version to 1.0.5
Right click on your project, click the Edit <projectname>.csproj option and modify the TargetFramework element value to netstandard2.0
This will should generate .NET Standard 2.0 assemblies with all the artifacts created by the Azure Functions tooling.
As of today I have been able to target .Net Standard 2.0 in a "reasonably" intuitive way and without editing any .csproj files.
You need a reasonably recent version of Visual Studio. I'm using Visual Studio Professional 15.5.3 (although I would guess that community would work).
You need to have the Azure development workload installed. This will install an extension called Azure Functions and Web Jobs Tools.
So far so plain vanilla. There were 2 additional bits that were to me not at all intuitive but ended up being very easy to do - easy when you know how!
You need to make sure that the Azure Functions and Web Jobs Tool is 15.0.31114.0 or greater - that's when they added .net core 2.0 support (see https://github.com/Azure/Azure-Functions/blob/master/VS-AzureTools-ReleaseNotes.md). You can update this using Tools/Extensions and Updates, or see https://marketplace.visualstudio.com/items?itemName=VisualStudioWebandAzureTools.AzureFunctionsandWebJobsTools
Even when you've done that, Visual Studio is a tiny bit weird about letting you create Azure Functions that target .net 2.0. When you go File/New Project, nothing has changed in the list of available project types, and if you select Azure Functions, the list of Frameworks just shows .NET Framework *, no .NET Standard, no .NET Core.
But if at this point you persevere and select Azure Functions, you then get a new dialog I hadn't seen before, which allows you to select Azure Functions v2 Preview (.NET Core).
Now, when I then look at the project properties, it turns out it is targeting .NET Standard 2.0, which in turn seems to contain Microsfot.NETCore.Platforms (1.1.0). So is this .net core 2.0 or not? Not quite sure but its' good enough for my purposes so now going to tuck into some coding.
Cheers!
For now, it's a manual process. You need to create .NET Standard 2.0 library, add function.json manually and run it with core tools.
the package Microsoft.NET.Sdk.Functions does not yet support .NET Standard 2.0 class libraries. This is the package that identifies a project as Functions project to Visual Studio and generates function.json from attributes during build.
You can still author C# class libraries that target .NET Standard 2.0, but you must use a manually-authored function.json. The templates for C# class libraries aren’t yet available in the Core Tools, but you can get a sample from GitHub.
from Develop Azure Functions on any platform
Update: 1.0.5 version of SDK should now support it, as mentioned by Fabio.

Using mono assemblies from the .NET CoreCLR

I need to consume a library that doesn't yet have CoreCLR support (RabbitMQ.Client, to be specific). Is it possible to utilize a mono-based port of that library on a Linux system from inside a CoreCLR executable? If so, how is that achieved?
It is impossible at binary level (unless using a proper PCL profile). .NET Core has a different approach to arrange classes in assemblies, so some assemblies on desktop .NET Framework are broken into smaller assemblies, and types are moved. A desktop targeting assembly (from .NET or Mono) won't work on .NET Core due to such changes.
But it is obviously possible at source code level, as there was an attempt to port Mono's WinForms to .NET Core,
http://forums.dotnetfoundation.org/t/anyone-porting-winforms-mono-to-net-core/898/4
Once a new .NET Core library project is created, the source files should be able to be carried over (with some modification or even none).
However, .NET Core has been evolving too fast, and that attempt might be now out of date. Anyone would like to explore in this area can follow that example and try once again. Good luck.

InstallShield Extension Condition DLL in .NET

I'm writing a Suite Installer in InstallShield 2012 Spring Premiere and am including an Extension Condition DLL in the project. I have a .NET version of the library that is included with my application and I'd like to add on the Extension Condition APIs to it so that I don't have to write a C++ version of the exact same code.
Has anyone done this before? Is there a sample project I can look at? KB Article reference?
Many thanks!
may be you can make your .Net Dll COM Visible. Look at this article.
http://jumbloid.blogspot.ca/2009/12/making-net-dll-com-visible.html

How to run C# 4.0 app on Linux OS using mono?

I want to run my c# application with OS Linux using Mono. I am new to this cross platform migration? Please tell the procedure for doing that?
Thanks & Regards.
It very much depends on what type of application it is. For a console or WinForms app, it may be simple. Mono doesn't support WPF.
Well, the first think you'll need to do is install Mono of course. Then you probably want to run MoMA to determine your application's compatibility. There's a whole separate page about porting WinForms apps.
If all is well, you should just be able to run your application using:
mono MyApplication.exe
after copying the binaries over.
If your application is actually a web service or web application, you'll want to think about the various hosting options.
I suspect you'll want to read a lot of the pages on the Mono Start Page.
Check if your application is 100% compatible with Mono Framework using MoMA.
Remove or replace those unimplemented parts with Mono's implementation or third party libraries that works with Mono. Or if you think it should work fine, just execute it with Mono Framework 2.8 or higher. Better go with 2.10 which is default's profile is on 4.0.
There is an IDE, MonoDevelop that supports Web and Desktop applications. Open the project files (monodevelop supports visual studio project files) from monodevelop, compile and run.
you can browse mono website here, where you can find which features are supported and which are not supported and why.

Resources