SSDT add assembly to deploy - wcf

I have old project that uses WCF from withing C# CLR triggers for SQL Server. I was always installing it by running a script.
But I've decided to move on to SSDT project on VS 2012. I've imported project from empty database.
WCF functionality depends on several assemblies from .net framework
SMdiagnostics
System.Web
System.Messaging
system.identitymodel
system.identitymodel.selectors
microsoft.transactions.bridge
System.ServiceModel
So I have a reference to these dlls in my project. I also had them added to my project under Assemblies sub folder.
However when I create a deployment script, these assemblies are not in it.
So when I try to publish script to database I receive an error.
Assembly 'system.servicemodel, version=3.0.0.0, culture=neutral, publickeytoken=b77a5c561934e089.' was not found in the SQL catalog.
If I try to create custom script to add assemblies to db :
create assembly [SMdiagnostics]
from 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\SMdiagnostics.dll'
with permission_set = unsafe
go
I receive error
Error: SQL70502: The assembly source is not valid. Only binary literals are allowed.
How can I add assembly from .NET to be deployed along with my SSDT project?
Thanks.

To add a .NET assembly to a SSDT project:
In Solution Explorer, expand the project and right-click References.
In the Add References window, either browse for the assembly or choose from the Assemblies category.
Right-click on the added assembly and click Properties.
Make sure these properties are set:
Generate Sql Script: True
Model Aware: True
Permission Set: Safe/External/Unsafe (depending on the assembly)
Press F5 to deploy to LocalDB/Debug destination or choose Publish and Generate Script to verify the changes.
DACPACs (the result of a SSDT build) doesn't allow CREATE ASSEMBLY with paths because the DLL isn't included and the path can't be guaranteed on another host. Therefore only embedded binary literals are allowed in the DACPAC.

Related

What is the difference between specifying a dependentAssembly in app.config and reference a dll in a .net project?

I have a .NET windows service made in VB.NET in Visual Studio 2013. In this project I have some DLLs referenced and also in app.config I have others defined as dependentAssembly (I didn't make this project).
When I compile this project, dependent assemblies specified in app.config are not being copied to output directory (debug or release depending on the case).
My questions are:
What is the difference between specifying dependent assemblies in app.config and reference a DLL?
Why dependent assemblies specified in app.config are not being copied to the output directory (debug or release) when compiling?
Can I force visual studio to copy dependent assemblies specified in app.config to outut directory (debug/release) when compiling?
Here is the relevant information I found about dependentAssembly. App.config should not be used on dlls, but only with executables.
If a dll is loaded in an executable, the dll will use the configuration file of the running executable and will ignore the configuration defined for him.
If you like, you can read the configured keys using some ugly code that takes them from the configuration file for the current assembly.
What you should do is put the relevant configuration into the exe configuration file. You can checked in this link for more details.

How to check GAC assembly details on Windows Server 2012?

How can you check GAC assembly details Windows Server 2012? I managed to register a DLL via Powershell, now I need to verify that it is really done.
You are probably looking for the custom look of the GAC directory that you were familiar with in .NET versions prior to 4.0. Which stored the GAC in the c:\windows\assembly window and used a custom shell extension to flatten the directory structure into a list of assemblies.
The shell extension is no longer used for .NET versions 4.0 and up. You have .NET 4.5 on that machine, its GAC is stored in c:\windows\microsoft.net\assembly. You just get to see the actual directory structure. Locating the assembly isn't that difficult, start in the GAC_MSIL directory and you should have no trouble locating your assembly there by its name. Locate the folder with the same display name as your assembly. It will have a subdirectory that has an unspeakable name that's based on the version and public key token, that subdirectory contains the DLL.
If your assembly is a mixed-mode assembly created with C++/CLI then you'd start from either the GAC_32 or GAC_64 directory.
just try with this path
C:\Windows\Microsoft.NET\assembly
An option would be to use PowerShell. I've created a PowerShell module which allows you to see and manipulate the GAC contents. You can find it here.
# Show the assemblies in the GAC, including the file version
Get-GacAssembly SomeCompany* | Format-Table -View FileVersion
The gacutil.exe has a parameter to do this. If you run
gacutil.exe /l
You will get a list of registrations.

TFS Build 2010 CodeActivity: Cannot Load Assembly in XAML

I am attempting to add a custom “activitycode” to a TFS Build. I wrote this months ago and had it working on a now defunct test environment. I am attempting to resurrect the use of the code onto a new test platform, and am running into issues.
When I open my build.xaml, I receive the dreaded red-box of pain where my custom activity should be, stating “Assembly could not be loaded because of an error in the XAML.” In the ErrorList, I also have found “Could not find type '.DeploySSRSReportActivity' in assembly 'ReportingServicesDeploy'.”
I have confirmed that my DLL is checked into source control and that the build controller is pointing to it.
Peeking into the raw XAML, I see that the build.xaml file defines the assembly as
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy
The line where my custom activity (and where V.S. finds the error) is:
<rsd:DeploySSRSReportActivity CurrentBuild="[BuildDetail]"
SourcesDirectory="[SourcesDirectory]"
mtbwt:BuildTrackingParticipant.Importance="High"
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
xmlns:mtvco="clr- namespace:Microsoft.TeamFoundation.VersionControl.Common;assembly=Microsoft.TeamFoundation.VersionControl.Common"
xmlns:ras="clr-namespace:ReportingServicesDeploy;assembly=ReportingServicesDeploy"
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy"
xmlns:sad="http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation"
xmlns:sad1="clr-namespace:System.Activities.Debugger;assembly=System.Activities" />
The DLL is named ReportingServicesDeploy.dll. The namespace within the DLL is ReportingServicesDeploy, and the name of the activity class is DeploySSRSReportActivity.
Where is the linkage failing so that I am getting that error?
When your attempting to edit the xaml your doing this on your machine directly, tfs and sourcecontrol is not involved, the location on server for controller is where build agent will look for assemblies during the build and where VS will get them when opening build definition for config.
Your error possibly is coused by old version being used.
The assemblies must be available for visual studio on your machine - one option is to add them to GAC or to post in VS bin folders. Start new instance of studio afterwards
To intall into GAC run this from Visual Studio command line:
gacutil /i "Path\To\YourAssembly.dll"
To remove assembly run following from Visual Studio command line:
gacutil /u "YourAssembly"
For studio assemblies i believe this is the folder:
Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies

How do I use COM reference within SSIS package?

I'm trying to use the Microsoft Shell Controls And Automation COM object library (C:\Windows\System32\shell32.dll) from within an SSIS Script Task to manipulate .zip archives.
Unfortunately, although I have successfully added the relevant Reference and the Script Task compiles OK. I'm using VB.NET, for what it's worth. I get the following runtime error as soon as I try to create any objects defined within the library:
Error: 0x1 at Archive File: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Interop.Shell32, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'Interop.Shell32, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at ST_a2650b7f39504eaa8c80e37a6736d957.vbproj.ScriptMain.Main()
I thought the Interop DLL would all be taken care of for me - does anyone know what step am I missing?
SSIS needs all .dll references to be registered with the GAC, you are correct.
You have different options regarding installing this dll into the GAC:
Drag and drop the .dll into the %windir%\assembly\ folder.
Use the gacutil.exe you are thinking about using: Regarding installing into the GAC using the gacutil, there is alot of useful information here: Global_Assembly_Cache. Basically, if you have the .NET framework installed (you are using VB.NET so no problem there), you will have a gacutil.exe in your Microsoft.NET folder.
(What I normally use when all else fails) Create a windows MSI project in Visual Studio that automatically does all this for you, useful info here: How to install assembly in the GAC using MSI
If you install that .dll in the GAC and you are still having problems, another option is to actually create a separate visual studio project that contains your logic for manipulating the needed zip files build it and call its exe from SSIS using the Execute Process Task. You can pass arguments specified in the SSIS package. Not very elegant, but it gets the job done if you are keen on using SSIS.
UPDATE:
The solution in this question did the trick SSIS Script Task COMException / FileNotFoundException error. The problem was in adding a signed reference of the dll, this answer provides a good step-by-step workaround for adding a COM reference within the SSIS Script Task.

Building a project with MSBUILD builds up-to-date, not specified projects (.NET 4)

I have a solution I am migrating from Visual Studio 2005 to 2010. Inside the IDE on developers machines, everything works fine, but my build server (with CC.NET) is giving me an error.
I have around 10 projects, 3 of which are not strong-named due to using unsigned references.
One of them (signed) has an InternalsVisibleTo another of the signed projects.
In the IDE I use Debug/Release configuration, which delay-sign all of the projects that are to be strong-named.
I also created Debug_Signed and Debug_Unsigned configurations (and the corresponding Release_*), which only build the corresponding projects.
In my build server I use the actual private key to build first the Debug_Signed configuration, and then call MSBUILD again on the Debug_Unsigned configuration with SingAssembly=false.
This worked perfectly fine using .NET 2.0 SDK, but now the first MSBUILD works fine, but then the second MSBUILD tries to rebuild the signed projects (since they are referenced by the unsigned projectes), and I get an error about one assembly having an InternalsVisibleTo a signed assembly while the generated assembly is not signed:
error CS0281: Friend access was granted to 'Sic.Gateway.Customers, PublicKey=0024...4bbe', but the output assembly is named 'Sic.Gateway.Customers, Version=2.0.0.796, Culture=neutral, PublicKeyToken=null'. Try adding a reference to 'Sic.Gateway.Customers, PublicKey=0024...4bbe' or changing the output assembly name to match.
What I would like is the second MSBUILD to use the reference assemblys that were just built by the first MSBUILD instead of trying to rebuild them.
The build server just has the .NET 4.0 runtime (not the SDK) and I had to copy two .targets files (for SQL/CLR and web applications). But since everything seems to build fine, I don't think that would be a problem.
Does anyone have any idea of what I can do?
Thanks,
Luis Alonso Ramos
(copied as answer from Luis' comment above)
When running MSBUILD for either the unsigned or signed assemblies I was specifying three properties:
SignAssembly=true\false;DelaySign=False;AssemblyOriginatorKeyFile=D:\blah\blah.s‌​nk
The thing is these properties applied to the whole solution, overriding the settings from individual projects. What I did was specify only the DelaySign and key file properties, without specifying SignAssembly. That way, the assemblies that are to be signed are still signed (with the new non-delay-signing settings), and those that shouldn't be signed are not.