I am following a tutorial that implements Chain Link's Aggregator V3 Interface, but it seems the code is not interacting properly with its import. Attempting to deploy on Remix brings up the error pictured below:
Here is the code I'm using to call it:
pragma solidity >= 0.6.6 < 0.9.0;
contract FundMe {
mapping(address => uint256) public addressToAmountFunded;
function fund() public payable {
addressToAmountFunded[msg.sender] += msg.value;
}
}
I posted on ethereum stack exchange with no luck, and also contacted Chain Link (they recommended Stack overflow). Any help is greatly appreciated, thank you (:
That error occurs when an abstract or interface contract is selected to deploy, and many imports are abstract or interfaces.
Ensure you select the correct contract in the "Deploy and Run Transactions" tab. If you want to choose the "FundMe" contract, make sure it is selected and not some other contract.
Related
I have read through the docs, but I still cannot figure out how a custom Azure DevOps task can associate a test result with a work item programmatically. I built a custom task that executes tests (running and executing outside Azure DevOps). When the tests finish and the results come back, I get the list of associated work items as well. I would like to call the appropriate Azure DevOps API to associate the test result with one or more work items. Any pointers would be welcome.
Test Result is also a kind of work item.
Thus you could use Rest API to handle this.
Use the Get Test Results REST API to get the test case from the
test result that you want to link to the work item:
Use the Get Work Item REST API to get the existing relations of
the work item (user story, task, etc) that you'd like to link to the
test result, and determine if the test result and/or test case are
already linked to the work item:
Uses the Update Work Item REST API to link the test result
and/or
test case to the work item:
More details of the sample and code snippet please refer Tanyan Harmon's comment in this related user voice: Need ability to link Test Results back to ANY work item type, especially User Stories
You could also follow the link shared by Matt in the comment.
Check this extension that I have created https://github.com/JanuszNowak/janono.ado.testcase.associate.cli
it allows associating in automatic manner. Code sample:
namespace ExampleTestProject
{
[TestClass]
[janono.ado.testcase.associate.Organization("janono-pub")]
public class UnitTest1
{
[TestMethod]
[janono.ado.testcase.associate.TestCase(5)] //<---
public void TestMethod1()
{
//yours test method content
//...
//
}
}
}
I have a simple custom Add-in that just displays a message to the user.
namespace GeorgiSpotfireCustomExtention
{
public class GeorgiEvent : CustomApplicationEventHandler
{
protected override void OnApplicationInstanceCreated(AnalysisApplication application)
{
base.OnApplicationInstanceCreated(application);
MessageBox.Show("On Application Instance Created");
}
}
}
That is my CustomAddIn class:
public sealed class CustomAddIn : AddIn
{
// Override methods in this class to register your extensions.
protected override void RegisterApplicationEventHandlers(ApplicationEventHandlerRegistrar registrar)
{
base.RegisterApplicationEventHandlers(registrar);
registrar.Register(new GeorgiEvent());
}
}
I am just trying to learn the package deployment process. When I am running it locally - in the installed Spotfire Analyst client it displays the message just fine:
However, when I package the extention, add it to the server (via the "Deployments & Packages" section, adding the "spk" file and then saving the area, the message is not shown when I try to open a document in the WebPlayer/Consumer.
Notes: I am choosing "TIBCO Spotfire Any Client" for my intended client in the Package Builder when building the spk file.
from the Spotfire Wiki (emphasis mine):
WinForms graphical user interface is a component of the .NET Framework and not something supplied by Tibco Spotfire. It's not recommended to implement solutions using Forms, but sometimes it could be handy when debugging. There is no commitment that it will work in future versions of the Analyst client. Forms are not supported on the Web Player.
the example listed on the wiki is for IronPython, but presumably the same holds true for C# extensions.
Correct. My assumption, and I don’t really know a lot about .NET, so this is not absolute, is that the form is rendered on the machine executing the code. In the case of your example above, the dialog would pop on the Node Manager host. If you’re really set on using an alert like this, you can accomplish it in JavaScript with an ‘alert()’. There is probably a way to render dialogues o in the web client too, but I don’t know it offhand.
We are building client for exchange server using python3.X as a language.
We found an existing library exchangelib, to perform all the basics operations including move, copy, delete etc email.
However we have an additional requirement to expand distributed list to get all the members of same.
Unfortunately this feature is not available in library.
Open Issue: https://github.com/ecederstrand/exchangelib/issues/93
Is there an alternate way to achieve same using web services provided by exchange.
If so any help on any relevant link will be of great help.
Thanks in advance.
As requested:
How to expand a distribution group by using the EWS Managed API or EWS in Exchange example:
private static void ExpandDistributionLists(ExchangeService service)
{
// Return the expanded group.
ExpandGroupResults myGroupMembers = service.ExpandGroup("Group1#contoso.com");
// Display the group members.
foreach (EmailAddress address in myGroupMembers.Members)
{
Console.WriteLine("Email Address: {0}", address);
}
}
source here or here
I am trying to switch a hosted worker process in Azure to use xml serializer instead of the default json serializer. I have done this by implementing IWantCustomInitialization like this:
public class BusInitialization : IWantCustomInitialization
{
public void Init()
{
Configure.Instance.XmlSerializer();
}
}
However when I start the cloud solution, I get the following error:
Exception when starting endpoint, error has been logged. Reason: Type NServiceBus.Unicast.Transport.CompletionMessage was not registered in the serializer. Check that it appears in the list of configured assemblies/types to scan.
When I use no custom initialization and it goes to JsonSerializer, everything is fine. Does anyone have a suggestion where shall I look to? I use NSB 3.2.8.
thought this was fixed but I just checked, looks like in 3.2.8 the jsonserializer cannot yet be overriden easily. This has already been fixed on the dev branch but didn't get into release yet, it will be in the next one than.
If you can't wait for next release then you can work around this by replacing the AsA_Worker with your own role and role handler similar to this:
3.2.8 version https://github.com/NServiceBus/NServiceBus/blob/master/src/azure/Hosting/NServiceBus.Hosting.Azure/Roles/Handlers/WorkerRoleHandler.cs
develop version https://github.com/NServiceBus/NServiceBus/blob/develop/src/azure/Hosting/NServiceBus.Hosting.Azure/Roles/Handlers/WorkerRoleHandler.cs
Kind regards,
Yves
I am designing a system using domain driven design concepts and I am struggling with a few things. The "domain" is essentially a business system for the company I work for. I am also using dependency injection. So, in my model I have things related to any typical business system (Employee, Order, Invoice, Deposit, etc..). Right now I am trying to create a cash posting application in which users (aka Employees) can create deposits and apply them to unpaid invoices. The problem that I am having is that we are also using an external business system (Microsoft Dynamics Nav) to handle our accounting transactions. So essentially I am dealing with two different databases. So, for the cash posting application I have modeled the domain objects Deposit and DepositLine. I also have in my domain an IDepositRepository interface that is responsible for persisting the deposits. To get a deposit from the system I just want to grab it directly from the database. However, in order to create a deposit I have to use the Dynamics Nav web services because there is certain logic that gets executed behind the scenes that I don't know about. I started looking at the concept of an Anti Corruption layer in which I could translate my version of the deposit object into a deposit object suitable for the web service. So here is what I am envisioning right now:
Domain Layer
- Models
- Deposit
- DepositLine
- Repositories
- IDepositRepository
Infrastructure Layer
- Data
- Repositories
- DepositRepository
- DynamicsNav
- Services
- INavCashManagementService
- Translators
- IDepositTranslator
- Adapters
- INavAdapter
Now I thought i might implement the DepositRepository like so:
public class DepositRepository
{
private INavCashManagementService navCashManagementService;
public DepositRepository(INavCashManagementService navCashManagementService)
{
this.navCashManagementService = navCashManagementService;
}
public Deposit GetDeposit(int id)
{
// use nhibernate to get directly from the database
}
public void SaveDeposit(Deposit deposit)
{
this.navCashManagementService.CreateDeposit(deposit);
}
}
First of all, is this an appropriate design? My next problem is that users are also going to have to "Post" deposits. The Nav web services will also have to be used to run the posting routine. But, this is more of a business process rather than a persistence issue, so I don't see it fitting into the repository. So I am wondering how/where I should call the posting routine. Should I create a domain service like this:
public class CashPostingDomainService
{
private INavCashManagementService navCashManagementService;
public CashPostingDomainService(INavCashManagementService navCashManagementService)
{
this.navCashManagementService = navCashManagementService;
}
public void PostDeposits()
{
this.navCashManagementService.PostDeposits();
}
}
One confusion I have with domain driven design is external dependencies. Doesn't the CashPostingDomainService class now have an external dependency on Nav? I know the implementation isn't in the domain layer, but doesn't the interface itself make it a dependency? The same goes with other technical concerns like sending emails. If I have an IEmailService interface and want to send an email once the deposits are posted, would I inject the interface into the CashPostingDomainService class? Or would that be part of the application workflow? So which one of these options make the most sense (if any):
1
public class DepositController
{
private ICashPostingDomainService cashPostingDomainService;
private IEmailService emailService;
public DepositController(
ICashPostingDomainService cashPostingDomainService,
IEmailService emailService)
{
this.cashPostingDomainService = cashPostingDomainService;
this.emailService = emailService;
}
public void PostDeposits()
{
this.cashPostingDomainService.PostDeposits();
this.emailService.NotifyDepositsPosted();
}
}
2
public class DepositController
{
private ICashPostingDomainService cashPostingDomainService;
public DepositController(
ICashPostingDomainService cashPostingDomainService)
{
this.cashPostingDomainService = cashPostingDomainService;
}
public void PostDeposits()
{
this.cashPostingDomainService.PostDeposits();
}
}
public class CashPostingDomainService
{
private INavCashManagementService navCashManagementService;
private IEmailService emailService;
public CashPostingDomainService(
INavCashManagementService navCashManagementService,
IEmailService emailService)
{
this.navCashManagementService = navCashManagementService;
this.emailService = emailService;
}
public void PostDeposits()
{
this.navCashManagementService.PostDeposits();
this.emailService.NotifyDepositsPosted();
}
}
Thanks for the help!
is this an appropriate design?
It seems fine to me. The important thing is for your Repository to stay oblivious of the Nav side of things and let the anticorruption layer handle that. You might want to have a look here for a similar example.
I know the implementation isn't in the domain layer, but doesn't the
interface itself make it a dependency?
You may have that feeling because the name of your (supposedly agnostic) service interface contains "Nav". To reflect a service abstraction that could have Nav or any other ERP as an implementation, you should rename it to ICashManagementService.
If I have an IEmailService interface and want to send an email once
the deposits are posted, would I inject the interface into the
CashPostingDomainService class? Or would that be part of the
application workflow?
It's your architectural decision to choose one or the other.
Option 1. means that sending an email is an intrinsic part of the deposit posting domain operation. If you take your domain module and reuse it in another application, posting deposits will automatically result in sending an email whatever that application is about. This might be the right thing to do in your context, or you might want to make things a little more generic (like, sending feedback after the operation but not deciding in the domain service whether this feedback should be mail, a log file, etc.)
Option 2. means that the sequence of events that happen after posting the deposits is application specific, that is at the use case level rather than business/domain level. It is up to the Controller (or Application Service) to decide which actions to take -send an email or anything else. Consequently, different applications based around your domain layer could decide to take different actions. This also means possible code duplication between these applications if several of them chose to send mails.