Что я могу сделать с C# и Powershell?
Комментарий
Комментарий в каждой ячейке заголовка ListObject остается там, если столбец переименован или переставлен.
Если (!) вы можете скрыть все комментарии по Application.DisplayCommentIndicator = xlNoIndicator (все комментарии не распознаются красным треугольником и не видны при наведении курсора), это может быть обходной путь:
Private Sub RecognizeColumnsOfListObject()
Dim lo As ListObject
Dim lc As ListColumn
For Each lo In ActiveSheet.ListObjects
For Each lc In lo.ListColumns
Debug.Print lc.Index ' not unique, always 1, 2, 3, ...
Debug.Print lc.Name ' not unique, changeable
If Not lc.Range.Cells(1).Comment Is Nothing Then
Debug.Print lc.Range.Cells(1).Comment.text ' unique
End If
Next lc
Next lo
End Sub
Named Range
Если я присваиваю каждой ячейке заголовка a ListObject имя, она перемещается вместе со столбцом, если я переставляю ListObject. Поскольку его Name.Value или Name.RefersTo начинается с =<ListObjectName>..., я получаю абсолютный адрес следующим образом:
Dim n As Name
With <sheet_codename>
For Each n In .Names
Debug.Print .Range(Mid(n.RefersTo, 1)).Address
Next n
End With
5 ответов
Нижний регистр верблюда рекомендуется для полей и параметров.
Пример 1 :
fileName // for fields, parameters, etc.
FileName // for properties, class names, etc.
Обычно используется fileName , а НЕ filename ; Вы можете убедиться в этом, прочитав исходный код материалов с открытым исходным кодом, созданных Microsoft, таких как Enterprise Library .
Причины :
- Основным пунктом за этим является что имена в этом случае более читабельны.
- Также этот подход добавляет согласованность , когда несколько параметров (полей, переменных ..) используются в одном и том же методе (классе ..) и с тем же префиксом " файл ", как показано ниже:
- ... Есть несколько других причин, но они более субъективны. По сути, это плагины для PowerShell, которые написаны в управляемом коде и действуют как обычные функции. У них есть пара глагол-существительное, и многие из функций, которые вы уже используете, на самом деле являются командлетами под капотом.
На самом высоком уровне у вас есть две разные опции. Вы можете из PowerShell хоста программы на C # и выполнять команды PowerShell через RunSpaces и конвейеры.
Или вы можете из PowerShell запустить код C #. Это можно сделать двумя способами. С помощью оснастки PowerShell, скомпилированной библиотеки DLL, которая предоставляет командлеты PowerShell и провайдеров навигации, или с помощью нового командлета Add-Type , который позволяет динамически импортировать код C #, VB, F #. Из справки
$source = @"
public class BasicTest
{
public static int Add(int a, int b)
{
return (a + b);
}
public int Multiply(int a, int b)
{
return (a * b);
}
}
"@
Add-Type -TypeDefinition $source
[BasicTest]::Add(4, 3)
$basicTestObject = New-Object BasicTest
$basicTestObject.Multiply(5, 2)
Ответ: «Это зависит от обстоятельств». С C # можно делать самые разные вещи (создавать окна, веб-клиенты и мобильные клиенты).
Вы можете вызывать сценарии PowerShell из C #. Посмотрите на этот сайт ==> ссылка
Вы даже можете преобразовать свой код на C # в powershell ==> ссылку
Вы можете посмотреть на это одним из двух способов:
- Как вы можете использовать PowerShell внутри вашей программы C #
- Как вы можете использовать программирование на C # внутри PowerShell.
] В некоторой степени это совершенно разные вопросы с разными ответами.
Из C # вы можете использовать движок PowerShell, пространства выполнения, конвейеры и т. Д. Как и в Exchante, вы можете использовать C # для всего графического интерфейса. , а затем вызовите командлет PowerShell для выполнения всех сложных задач. Этот вариант подходит, если вы можете найти командлеты или сценарии PowerShell для использования.
Из PowerShell вы используете C # для расширения возможностей PowerShell. Вы можете создавать cmdlts и поставщиков, чтобы другие пользователи могли получать доступ к данным приложения. Или вы можете просто создавать объекты, которые можно использовать в сценарии PowerShell. Этот вариант помогает открыть приложение для более автоматизированного управления.
Итак, в зависимости от того, что вы хотите сделать, у вас есть варианты.
Скотт Хансельман, также известный как Hanselminutes , опубликовал несколько подкастов о Powershell, CmdLets, C # и многом другом. Лучше всего, если вы хотите узнать, что это такое, как это работает и многое другое. Выполните поиск на его веб-сайте, чтобы найти подкаст.
Список подкастов, связанных с PS на его сайте (в обратном хронологическом порядке):
# 190: State of Powershell / Lee Holmes & Jason Shirk
# 162: Powershell 2.0
№ 49: Powershell / Брюс Пайетт
№ 36: Джеффри Сновер, архитектор Powershell
№ 24: Windows Powershell (MONAD), часть II