Включая сервисную ссылку от библиотеки классов
groupby в axis=1
Если мы передаем вызываемый, который возвращает то же значение, мы группируем все столбцы вместе. Это позволяет нам использовать groupby.agg, который дает нам метод first, который делает этот простой
df.groupby(lambda x: 'Z', 1).first()
Z
0 1.0
1 3.0
2 4.0
3 NaN
. Это возвращает фреймворк с именем столбца вещи, которую я возвращал в своем вызываемом
lookup, notna и idxmax
df.lookup(df.index, df.notna().idxmax(1))
array([ 1., 3., 4., nan])
argmin и нарезка
v = df.values
v[np.arange(len(df)), np.isnan(v).argmin(1)]
array([ 1., 3., 4., nan])
5 ответов
Думайте о том, что Вы пытаетесь сделать - у Вас есть два блока, которые Вы создаете:
Library
ConsoleApp
Оба из этих блоков имеют конфигурационные файлы - я предположил бы, что они выглядят примерно так:
Library
app.config
ConsoleApp
ConsoleApp.exe.config
, Когда Вы работаете ConsoleApp, это не имеет никакого способа читать из или знать приблизительно app.config от Вашего Library блок. Единственный конфигурационный файл, который это знает или заботится о, ConsoleApp.exe.config. Теперь возможно иметь ссылку конфигурационных файлов друг друга, но это не надлежащее решение для того, что Вы пытаетесь сделать.
Начиная с Вашего Library блок не имеет никакой точки входа, он никогда не будет загружаться в AppDomain. Так как это никогда не будет загружаться в AppDomain, его файл конфигурации приложения никогда не будет использоваться.
то, Что необходимо сделать, ссылочное Library в ConsoleApp через ссылку проекта. Затем переместите все соответствующие данные конфигурации от app.config в [1 110], поскольку это - конфигурационный файл, который будет использоваться Вашим приложением.
Это позволит Вам иметь к двум вещам, необходимо вызвать методы на веб-сервис
- код в [1 111], который может отправить и получить сообщения SOAP.
- метаданные конфигурации, которые требуются [1 112] функционировать.
Можно скопировать соответствующие части app.config от конфигурации библиотеки классов в app.config для консольного приложения.
, С другой стороны, если Вы действительно пытаетесь сделать это действительно портативным, необходимо будет думать о другом способе сослаться на адрес для определенной сервисной ссылки из библиотеки классов.
Просто необходимо скопировать ключ конфигурации, указав на сервис, от файла конфигурации библиотеки классов до консольного файла конфигурации приложения.
Я думал бы это более сбивающий с толку, если бы у Вас было несколько обтекающих конфигурационных файлов.
, Если бы библиотека имеет настраиваемые объекты, я полностью ожидал бы должным быть помещать ту конфигурацию в свой файл конфигурации для надлежащего потребления библиотеки.
Альтернативой использованию ссылки на службу в библиотеке классов и последующему копированию конфигурации было бы использование событий сборки, которые вызывают svcutil.exe. Что мне нравится в этом, так это то, что вам не нужно делать «ссылку на службу обновлений» при изменении службы. Он будет обновляться автоматически.
В библиотеке классов используйте событие сборки, которое генерирует только прокси-код:
svcutil.exe net.tcp://localhost:3315/MyService/mex /noConfig
В приложении используйте событие сборки, которое генерирует конфигурацию. Вы можете использовать параметр / mergeConfig, чтобы объединить его с существующим app.config.
svcutil.exe net.tcp://localhost:3315/MyService/mex
/config:App.config /mergeConfig
Если вы не хотите получать ошибку сборки, если служба не запущена, поместите это в файл проекта, и вы получите предупреждение вместо ошибки:
<Target
Name="PreBuildEvent"
Condition="'$(PreBuildEvent)'!=''"
DependsOnTargets="$(PreBuildEventDependsOn)">
<Exec WorkingDirectory="$(OutDir)"
Command="$(PreBuildEvent)"
ContinueOnError="true" />
</Target>