I have a cake file with my Tasks defined.
I also have a second cake file with some classes defined.
In the second file, I would like to reference e.g. Cake.Json, and maybe Cake.Svn. But I cannot figure out how reference them.
How would I do that?
Both addins and utility Cake scripts are references using pre-processor directives.
Addin directive
Usage
#addin nuget:?package={NuGet Package Id}&version={NuGet package version}
Example:
#addin nuget:?package=Cake.Json&version=3.0.1
Reference directive
Usage
#r "Path to assembly / dll"
Example:
#r "bin/Cake.Json.dll"
Load directive
Usage
#load "Path to cake file"
Example:
#load "scripts/common.cake"
Reference
Read more about pre-processor directives at
https://cakebuild.net/docs/fundamentals/preprocessor-directives
Related
I want to use System.Data in my cake script, to perform some DB operations.
My script is sth like this:
#r "System.Data"
void DoSomething()
{
System.Data.SqlConnection conn = new System.Data.SqlConnection(..);
}
However, this does not compile resulting in error
error CS0246: The type or namespace name 'SqlConnection' could not be found (are you missing a using directive or an assembly reference?)
What is the proper way to reference System assemblies (from GAC) in Cake scripts?
System.Data is already loaded with cake.
Your problem is the namespace of SqlConnection.
The correct NS is System.Data.SqlClient.SqlConnection
your file can just have this
using System.Data.SqlClient;
void DoSomething()
{
SqlConnection conn = null;
}
You can use intellisense as well if you are using vs code.
Go to Extensions and add Cake Extension.
Then open command pallete and select Add tool from Nuget.
and just Type Cake.Bakery and install it.
Run the build script once and restart the vs code again.
You will get intellisense. Not to worry.
I'm little confused by various terminologies used in the SystemJS configuration. It talks about module, location, package etc...
Isn't module in JS is a single file, and package is a collection of modules or files? If so, how a module can be an alias to a package?
This is from the documentation page:
The map option is similar to paths, but acts very early in the normalization process. It allows you to map a module alias to a location or package:
Yes module is a single file, in javascript it's just the file name (with assumed .js extension) in quotes after from keyword in
import ... from 'some-module';
In SystemJS config file, paths and map can be used to define what actual file or URL that some-module refers to.
packages in config file allow you to apply a set of configuration parameters (default extension, module format, custom loader etc) for all modules in or below particular location (the key in packages object).
One of the settings in packages is main, which is similar to main in package.json in node (except that it's default value is empty, not index.js): it determines which file is loaded when the package location itself appears in from in import statement.
So, I think "how a module can be an alias to a package?" question about this
The map option is similar to paths, but acts very early in the
normalization process. It allows you to map a module alias to a
location or package:
can be explained on this example:
paths: {
'npm:': 'node_modules/'
},
map: {
'some-module': 'npm:some-module'
},
packages: {
'some-module': {
main: './index.js'
}
}
when these map, packages and path settings are applied by SystemJS to
import something from 'some-module';
they will cause SystemJS to load a module from node_modules/some-module/index.js under baseURL.
and
import something from 'some-module/subcomponent';
is mapped to node_modules/some-module/subcomponent.js.
Note: this is based on my experience with SystemJS 0.19. I haven't tried 0.20 yet.
I have a Swift library with a core module plus optional bonus modules. I would like to use the following directory layout, mapping to exported Swift package names as shown:
Taco/
Source/
Core/ → import Taco
Toppings/ → import TacoToppings
SideDishes/ → import TacoSideDishes
To my eyes, that’s a sensible-looking project layout. However, if I’m reading the docs right, this will pollute the global module namespace with unhelpful names like “Core”. It seems that SwiftPM will only export a module whose name is identical to the directory name, and thus I have to do this:
Taco/
Source/
Taco/
TacoToppings/
TacoSideDishes/
Is there a way to configure Package.swift to use the tidier directory layout above and still export the desired module names?
Alternatively, is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
There is not currently a clean way to do this, but it seems like a reasonable request. I recommend filing an enhancement request at http://bugs.swift.org for it.
There is one "hacky" way you can do this:
Create your sources in the desired internal layout:
Sources/Core
Sources/Toppings
Add additional symbolic links for the desired module names:
ln -s Core Sources/Taco
ln -s Toppings Sources/TacoToppings
Add an exclude directive to the manifest to ignore the non-desired module name:
let package = Package(
name: "Taco",
exclude: ["Sources/Core", "Sources/Toppings"]
)
is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
No, unfortunately there is no way to do this currently, and it requires substantial compiler work to be able to support.
I'm writing a PowerShell module which depending on the SMO assemblies in SQL Server. (The only one I need to reference is Microsoft.SqlServer.Smo.dll)
When I've been developing module. I've just taken a copy of the assembly I need and referenced it in my manifest file similar to this:
RequiredAssemblies = #(
"$env:userprofile\Documents\WindowsPowerShell\Modules\Dependencies\Microsoft.SqlServer.Smo.dll"
)
I would assume that in a production environment you'd want to reference assemblies from a standard location. I'd assume a standard location would be the GAC.
If I reference the assembly from the GAC, I get this, but this looks like it could break if a new version of the assembly is installed:
RequiredAssemblies = #(
'C:\WINDOWS\assembly\gac_msil\Microsoft.SqlServer.Smo\12.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Smo.dll'
)
I could also reference the assembly directly from the SDK:
RequiredAssemblies = #(
'C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.Smo.dll'
)
Another option I've considered (but possibly might be breaking a EULA somewhere) is to copy the assemblies to a server share and reference that like so:
RequiredAssemblies = #(
'\\MyServer\PowerShellDependencies\Microsoft.SqlServer.Smo.dll'
)
But how should I be doing this?
If it's relevant, all computers that this module will be installed on are 64-bit and will have the SMO libraries installed. Also, this isn't a publicly available piece of software, it's being deployed on a company network.
Update: I've tried only specifying the name of the assembly in the manifest and this appears to work.
RequiredAssemblies = #(
'Microsoft.SqlServer.Smo.dll'
)
Unless you're going to deploy the SMO assemblies as private assemblies, then I wouldn't recommend loading them from direct references.
To load from the GAC, use the Add-Type cmdlet with the fully qualified assembly name...
Add-Type -AssemblyName "Microsoft.SqlServer.Smo, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"
Related:
How do I use Add-Type to load Microsoft.Web.Deployment?
You can also specify just the assembly without the version info:
Add-Type -AssemblyName "System.Xml.Linq"
Let's say that I want to define a module "Pair" in com.mycompany.common such that the source is located in com.mycompany.common (and not com.mycompany.common.client). How would I do this? Alternatively, let's say that I have the flexibility of defining the module "Pair" in com.mycompany instead while still having the source in com.mycompany.common.
Thanks to a quick search on google, I found the answer myself. One can add a source path tag to the module xml file to define the source directory instead of leaving it to the default "client." For example, Pair.gwt.xml would look something like this:
<module>
...
<source path="."/>
...
</module>
... if we wanted the gwt.xml file to be in the same directory as the source.
But when compiling this module, we get a "Non-canonical source package: ./" warning. Is this ok to ignore?