We Keep Coding

Powershell v4 not importing module automatically

I am using Microsoft PowerShell v4:
PS C:\> get-host
Name : ConsoleHost
Version : 4.0
InstanceId : 3b4b6b8d-70ec-46dd-942a-bfecf5fb6f31
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : de-CH
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace
I have developed a C# project in Visual Studio 2012 targeting .NET Framework 4 which contains some Cmdlet and the Snapin. I can debug them and everything works just fine.
I've created the path C:\PowerShell\Modules\ and added it to the PSModulePath environment variable.
I put the rMySnapIn.dll to the path C:\PowerShell\Modules\MySnapIn.
I would expect that the module is automatically loaded so I have my new cmdlets ready to use, but they're not: the module is not loaded. I have to write Import-Module MySnapin in order to get it loaded.
How can I get the module automatically loaded?

A checklist that may help you identify the issue:
According to What's New in Windows PowerShell, "Automatic importing of modules is triggered by (a) using the cmdlet in a command, (b) running Get-Command for a cmdlet without wildcards, or (C) running Get-Help for a cmdlet without wildcards." (That applies to V3 and V4.) How did you confirm the module was not loaded?
According to about_Modules, "Only modules that are stored in the location specified by the PSModulePath environment variable are automatically imported." You stated that you did add your path to PSModulePath. When I examine mine, I see that each path included is terminated with a backslash, so in your case you would need C:\PowerShell\Modules\ rather than just C:\PowerShell\Modules. What is the value of your $env:PsModulePath ?
According to this post from Thomas Lee as well as my own experience, autoloading does not work with script modules; however, you state you are using a compiled module, so this should not be your issue.
The $PSModuleAutoLoadingPreference preference variable can be used to turn off autoloading; however, unless you have explicitly changed it, it defaults to All so likely that is not the problem (about_Preference_Variables shows you the possible values). What is your value of $PSModuleAutoLoadingPreference ?
Last but not least--I am particularly suspicious over the fact that you seem to be mixing snapins and modules. They are distinct types of entities, and are not designed to be mixed. Snapins are loaded via Add-PSSnapin. Modules are loaded via Import-Module. And modules, as you know, are also loaded by auto-loading--I suspect that may not be true of code written as a snapin. Furthermore, snapins are deprecated; new code should be written using modules (that is, derive from Cmdlet or PSCmdlet, as detailed in Writing a Windows PowerShell Cmdlet).

If you want to load it automatically you can add the Import-Module MySnapin command line to your PowerShell profile.
To find out the location of your PowerShell profile just type $profile in a PowerShell and by default the profile path is:
C:\Documents and Settings\User\My Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
If the Microsoft.PowerShell_profile.ps1 file does not exist just create it.

I noticed that following structure is not supported by PowerShell 4:
Modules\MySnapIn\1.0.0\MySnapIn.psm1
Works fine after update to version 5.

Note: I'm authoring only script modules, so I may be wrong.
PowerShell module autoload depends on command discovery. I suspect that if you create manifest (New-ModuleManifest) and name commands that your binary module exposes, autoloading should kick-in and load module if someone will try to use one of these commands:
New-ModuleManifest -Path MySnappin.psd1 -RootModule MySnappin.dll -CmdletsToExport Get-Foo, Set-Bar

Import scikit in C# application

I am trying to import scikit-learn in a C# (console) application. I am using Python Tools for Visual Studio and IronPython 2.7.3.
I managed to run an external python script and I also managed to import numpy by declaring the python path: "C:\Python27\Lib\site-packages\"
However, when it comes to scikit-learn I get an error message:
Oops! We couldn't execute the script because of an exception: No module named _c
heck_build
___________________________________________________________________________
Contents of C:\Python27\Lib\site-packages\sklearn\__check_build:
setup.py setup.pyc setup.pyo
_check_build.pyd __init__.py __init__.pyc
__init__.pyo
___________________________________________________________________________
It seems that scikit-learn has not been built correctly.
If you have installed scikit-learn from source, please do not forget
to build the package before using it: run `python setup.py install` or
`make` in the source directory.
If you have used an installer, please check that it is suited for your
Python version, your operating system and your platform.
The file "_check_build.pyd" exists in "C:\Python27\Lib\site-packages\sklearn__check_build\".
My code is based on this article: http://devleader.ca/2013/09/23/visual-studio-c-python-sweet/
The file I am using has only the following code:
from sklearn.svm import SVC
print('Hello Python in C#')
Is it possible to add and use scikit in C#? If yes, could you please provide a workaround?

Looks like scikit-learn requires a C extension, which means it won't run under IronPython.

Open Generic types won't register in the catalog

We're using .NET 4.5 and have had no problem with open generic exports in MEF up until a month ago when it suddenly stopped working. 70 tests on our CI server turned red and we traced it down to missing parts in the container.
I found it strange, so I wrote this test code:
var catalog = new TypeCatalog(typeof(Impersonator<>), typeof(Cache<>));
var parts = catalog.Parts;
But it looks like none of the open generic types will register in the catalog. Parts is a TypeCatalog with Types = <Empty>.
Usually we go about this by declarative exports using attributes as in this SO question, but none of the alternatives seems to be working anymore.
Any idea will be most appreciated.

Any idea what triggered it to start failing? Did you get a .NET update in that timeframe?
Out of curiosity if you write a simple console app targeting .NET 4.5 does this issue repro?
The reason I ask is I believe there was an update released for .NET 4.5 to make sure open generics didn't break existing .NET 4.0 apps and so if for some reason your tests are running in .NET 4.0 mode then then the open generic support will be disabled which could cause what you are seeing.

I resolved this in my web app by putting the entry < httpRuntime targetFramework="4.5" /> in my web.config. For non-web apps, make sure the app.config has the entry
< supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />.
see http://blogs.msdn.com/b/webdev/archive/2012/11/19/all-about-httpruntime-targetframework.aspx for more info.

I know this is an old issue, but I have some additional information that may help others.
I ran into the same issue. My unit tests were working then suddenly stopped. We narrowed it down to a pair of Windows updates: KB2840642v2 and KB2840642. After uninstalling these, MEF started working properly again in unit tests. I didn't see anything in the release notes for those updates that should affect things, but you know how that goes.
However, I am now running Windows 8 unfortunately, and the issue has popped up again. I do not have those updates installed. I think they were incorporated natively into the operating system.

When you say “on our CI server”, that does not tell us much about how you’re running the tests. However, I seem to get an experience like yours using vstest.console.exe.
I found a situation where MEF’s automatic open type closing feature, new in .net-4.5, will appear to break when running tests with vstest.console.exe. Basically, vstest.console.exe might decide to run in .net-4.0 compatibility mode as if /Framework:Framework40 had been passed to it. .net-4.5 assemblies will load and run perfectly fine even when loaded by a .net-4.0 runtime, but MEF detects that you’re running in .net-4.0 mode and disables its support for automatically closing open generic types. You can get MEF to behave properly again by forcing vstest.console.exe to run in .net-4.5 mode by passing the /Framework:Framework45 switch.
(This tested on a machine with .net-4.6.1 installed, though, not sure if that changes things yet more).
Minimal Repro
When I make a simple test assembly targeting the .net-4.5 framework, vstest.console.exe correctly guesses that it should run the tests with .net-4.5. However, when I make an assembly that integrates into a more complex build environment, vstest.console.exe suddenly starts running in .net-4.0 mode rather than .net-4.5 mode. So I started with my complex build environment and started paring things down until the issue disappeared.
To get vstest.console.exe to guess the wrong framework, you need two assemblies. In one, define a custom assembly Attribute. In another, apply that custom assembly attribute and define your unit tests.
First assembly:
using System;
[AttributeUsage(AttributeTargets.Assembly)]
public class BreakVSTestFrameworkDetectionAttribute : Attribute
{
}
Second assembly referencing the prior one:
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
[assembly: BreakVSTestFrameworkDetection]
[InheritedExport]
public interface IGenericService<T>
{
void Print(T thing);
}
public class SomeGenericService<T> : IGenericService<T>
{
public void Print(T thing) => Console.WriteLine($"{typeof(T)}:{thing}");
}
[TestClass]
public class UnitTest1
{
[TestMethod]
public void Run()
{
using (var catalogue = new ApplicationCatalog())
using (var container = new CompositionContainer(catalogue))
{
container.GetExportedValue<IGenericService<string>>().Print("asdf"); // System.String:asdf
container.GetExportedValue<IGenericService<int>>().Print(123); // System.Int32:123
}
}
static void Main(string[] args) => new UnitTest1().Run();
}
With these two assemblies and the defined test, I get the following outcomes in different scenarios:
Running the tests using Visual Studio 2015 Community Editions’s GUI works perfectly fine.
Running the code directly as an executable works fine.
C:\Users\ohnob\OneDrive\Documents\Visual Studio 2015\Projects\MefGenericsUnitTests>bin\Debug\MefGenericsUnitTests.exe
System.String:asdf
System.Int32:123
Running the tests with something like mstest (except I can’t tell why one would or wouldn’t use this instead of vstest) magically works (at least in this case) (output trimmed).
C:\Users\ohnob\OneDrive\Documents\Visual Studio 2015\Projects\MefGenericsUnitTests>"\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" /testcontainer:bin\Debug\MefGenericsUnitTests.exe
Microsoft (R) Test Execution Command Line Tool Version 14.0.23107.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading bin\Debug\MefGenericsUnitTests.exe...
Starting execution...
Results Top Level Tests
------- ---------------
Passed UnitTest1.Run
1/1 test(s) Passed
Running with straight up vstest.console.exe fails (output trimmed):
C:\Users\ohnob\OneDrive\Documents\Visual Studio 2015\Projects\MefGenericsUnitTests>"\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" bin\Debug\MefGenericsUnitTests.exe
Microsoft (R) Test Execution Command Line Tool Version 14.0.24720.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
Failed Run
Error Message:
Test method UnitTest1.Run threw exception:
System.ComponentModel.Composition.ImportCardinalityMismatchException: No exports were found that match the constraint:
ContractName IGenericService(System.String)
RequiredTypeIdentity IGenericService(System.String)
But vstest.console.exe /Framework:Framework45 succeeds:
C:\Users\ohnob\OneDrive\Documents\Visual Studio 2015\Projects\MefGenericsUnitTests>"\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" /Framework:Framework45 bin\Debug\MefGenericsUnitTests.exe
Microsoft (R) Test Execution Command Line Tool Version 14.0.24720.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
Passed Run
Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 3.7855 Seconds

I think you can not use open generic and should provide a concrete running class like:
var catalog = new TypeCatalog(typeof(Impersonator<type1>), typeof(Impersonator<type2>), typeof(Cache<type3>), typeof(Cache<type4>));
var parts = catalog.Parts;
I tried using interfaces like IImpersonator and ICache and does not work also:
interface IImpersonator { }
class Impersonator<T> : IImpersonator
...
var catalog = new TypeCatalog(typeof(IImpersonator), typeof(ICache));
var parts = catalog.Parts;

Class not registered error from PHP

We've created a C# class library assembly and made it COM visible to be able to call its methods from PHP. This used to work fine, but now we wanted to install it on a Windows Server 2008 server and we keep walking into the error "Class not registered".
To rule out any dependency problems I made a tiny little test class library in C#. The class library is built for Any CPU and it is COM visible (also set COMVisible to true in AssemblyInfo.cs). The test class library only contains one class with one method. The class is called TestLib and the namespace is also called TestLib. The method is called Test and only returns a string.
What we have done is the following:
- built the TestLib.dll
- copied it to the Windows Server 2008 machine
- registered the dll with: regasm /codebase TestLib.dll
- the regasm tool returns a success message
- in PHP we simply try to create a new COM instance:
try
{
$test = new COM("TestLib.TestLib");
}
catch (Exception $e)
{
die($e->getMessage());
}
when we call this test script from either the browser or the commandline (php -f test.php) we get the error "Class not registered" in both cases
I also tried adding TestLib to the GAC by using gacutil -i, but to no avail; still the class not registered error.
Then I tried compiling the testlibrary with .NET 2.0 instead of 4.0 as the target framework, same result. The .NET framework 4.0 is installed on the server by the way.
Any ideas?

Okay, so after some more research I figured it out. The php.exe process is 32 bit. The COM visible assembly is compiled for Any CPU so it should be accessible to both 32 and 64 bit applications.
The problem is that on a 64 bit OS php.exe, and any 32 bit process for that matter, searches in HKEY_CLASSES_ROOT\Wow6432Node\CLSID instead of HKEY_CLASSES_ROOT\CLSID and in HKEY_LOCAL_MACHINE\Software\Classes\Wow6432Node\CLSID instead of HKEY_LOCAL_MACHINE\Software\Classes\CLSID. The registry entries in the Wow6432 keys aren't created by regasm that is shipped with .NET framework v4 on Windows Server 2008. On Windows 7 they are created, don't ask me why.
It also turned out that if I create a little test assembly for .NET v2.0 and register it with regasm that ships with .NET framework v2.0 that it does create the Wow6432Node entries on Windows 2008. Strange.
So my solution is to create a basic registry file on the server using:
regasm /regfile MyClassLib.dll
This creates a file MyClassLib.reg with only the 'normal' 64 bit entries. Then I exported the Wow6432Node keys from a Windows 7 machine and added it to that .reg file. Now when I import that reg file into the registry on Windows 2008 everything works fine.
For more info on the Wow6432Node entries check out: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724072%28v=vs.85%29.aspx
Hope this saves someone else some time and headaches.

If you are trying to call a 32-bit COM DLL on 64-bit Windows, you will need to register it.
Copy your 32-bit DLL to C:\Windows\sysWOW64
Run C:\Windows\sysWOW64\regsvr32.exe your_com_32.dll
A bit more info with screenshots.

How can I call SSIS programmatically from .NET?

I have an application where whenever a file is uploaded to a directory, I have to call SSIS to parse the XML file.
Can I call a SSIS directly from a .NET Windows service?

Running SSIS package programmatically.
I prefer the second method:
Start DTEXEC.EXE process. DTEXEC is command line utility for executing SSIS packages. See its command line options here: http://msdn2.microsoft.com/en-us/library/ms162810.aspx
Benefits: running package out of process gains reliability. Can be used from any programming language (including .NET 1.1 :)). Easy to pass parameters by setting variables values.
Drawbacks: Also local only. Harder to get information about package progress (but SSIS logging can give you most functionality). Some overhead on starting new process (likely minimal compared to execution time for big packages).
ASP.NET specific: Win32 CreateProcess function ignores the thread impersonation. So if you want DTEXEC to run under account different from ASP.NET process account, you should either make user enter name/password and pass it to Process.Start, or use method described in the following KB to run child process under impersonated account http://support.microsoft.com/kb/889251.

you can run your SSIS package programmatically, as follow:
using System;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;
namespace ConsoleApplicationSSIS
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Loading SSIS Service...");
//Application object allows load your SSIS package
Application app = new Application();
//In order to retrieve the status (success or failure) after running SSIS Package
DTSExecResult result ;
//Specify the location of SSIS package - dtsx file
string SSISPackagePath = #"C:\Microsofts\BI\SSIS\ConsoleApplicationSSIS\IntegrationServiceScriptTask\Package.dtsx";
//Load your package
Package pckg = (Package)app.LoadPackage(SSISPackagePath,true,null);
//Execute the package and retrieve result
result = pckg.Execute();
//Print the status success or failure of your package
Console.WriteLine("{0}", result.ToString());
Console.ReadLine();
}
}
}
if you want a complete sample, go to :http://hassanboutougha.wordpress.com/2012/10/13/run-your-ssis-package-progammatically/
I explain how create a simple SSIS package and after how to call it programmatically from a console application. Don't forget to have this assembly :C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.DTSRuntimeWrap.dll to reference runtime ssis namespace
you can also pass your variables programmatically and change also source and destination connections of your ssis package

You can call SSIS programtically, execute the package and change the configuration from a .NET code using DTS runtime. Here is complete code of how you can do it.

You can call the SSIS package from your windows service. But Microsoft.SqlServer.Dts should be installed into the system where windows services are going to run. If you have installed DTS installed in that machine, directly call the SSIS package. If it is not installed then you should do the following.
Create the SSIS package
Create the job which runs the SSIS package
In your ADO.NET[resides in windows services code], Call stored
procedure which runs job[configured to run the SSIS package].
Following is an example should be called from your .NET code.
EXEC msdb.dbo.sp_start_job N'YourJobName'
Hope this helps!

Updating this pretty old question:
On SQL Server 2012 you can do this simply by creating stored procedure that will call to create_execution and set_execution_parameter
Step-by-step guide can be found here: https://blogs.msdn.microsoft.com/biblog/2013/05/07/step-by-step-of-executing-ssis-2012-package-through-stored-procedure/